On Fri, 29 Sep 2017 17:33:11 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
That said, we may also want to consider a couple of other options related to changing the meaning of *existing* parameters to these APIs:
1. We have the PyCompilerFlags struct that's currently only used to pass around feature flags for the __future__ module. It could gain a second bitfield for optimisation options
Not sure about that. PyCompilerFlags describes options that should be common to all implementations (since __future__ is part of the language spec).
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 said, perhaps it makes implementation easier on the C side... Regards Antoine.