[Python-ideas] Changes to the existing optimization levels
Nick Coghlan
ncoghlan at gmail.com
Mon Oct 2 03:51:56 EDT 2017
More information about the Python-ideas mailing list
Mon Oct 2 03:51:56 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 ]
On 1 October 2017 at 22:19, Antoine Pitrou <solipsis at pitrou.net> 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 > > Well, this is not really a bitfield, but a bitfield plus some irregular > hardcoded values. Therefore I don't think it brings much in the way of > discoverability / understandability. That's why the 2-field struct for compiler flags was my first idea. > That said, perhaps it makes implementation easier on the C side... Yep, the fact it would avoid requiring any ABI changes for the C API is the main reason I think redefining the semantics of the existing int parameter is worth considering. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- 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