[Python-ideas] Changes to the existing optimization levels
Diana Clarke
diana.joan.clarke at gmail.com
Fri Sep 29 16:24:52 EDT 2017
More information about the Python-ideas mailing list
Fri Sep 29 16:24:52 EDT 2017
- Previous message (by thread): [Python-ideas] Changes to the existing optimization levels
- Next message (by thread): [Python-ideas] Changes to the existing optimization levels
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Oh, I like this idea! I had very briefly considered treating the existing flag as a bitfield, but then promptly forgot to explore that line of thought further. I'll play with that approach next week, see where it takes me, and then report back. Thanks so much for taking the time to think this through with me – much appreciated. Cheers, --diana On Fri, Sep 29, 2017 at 1:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: > 2. We could reinterpret "optimize" as a bitfield instead of a regular > integer, special casing the already defined values: > > - all zero: no optimizations > - sign bit set: negative -> use global settings > - 0x0001: nodebug+noassert > - 0x0002: nodebug+noassert+nodocstrings > - 0x0004: nodebug > - 0x0008: noassert > - 0x0010: nodocstrings > > The "redefine optimizations as a bitfield" approach seems particularly > promising to me - it's a full integer, so even with all negative > numbers disallowed and the two low order bits reserved for the legacy > combinations, that's still 29 different optimisation flags given > 32-bit integers. We currently have 3, so that's room for an 866% > increase in the number of defined flags :)
- Previous message (by thread): [Python-ideas] Changes to the existing optimization levels
- Next message (by thread): [Python-ideas] Changes to the existing optimization levels
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-ideas mailing list