On Fri, 29 Sep 2017 17:33:11 +1000 Nick Coghlan <ncogh...@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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
