[Python-ideas] Changes to the existing optimization levels
Diana Clarke
diana.joan.clarke at gmail.com
Tue Oct 3 11:42:40 EDT 2017
On Sun, Oct 1, 2017 at 6:19 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> 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...
I think I'm coming to the same conclusion: using bitwise operations
for the optimization levels seems to just boil down to a more cryptic
version of the simple "level 3" solution, with public-facing impacts
to the pycache and existing interfaces etc that I don't think are
worth it in this case.
My only other thought at the moment, would be to use the existing -X
option to achieve something similar to what I did with the new -N
option, but then just quickly map that back to an integer under the
hood. That is, "-X opt-nodebug -X opt-noassert" would just become
"level 3" internally so that the various interfaces wouldn't have to
change.
But there are lots of downsides to that solution too:
- having to hardcode the various possible combinations of string
options to an integer value
- inelegant lookups like: if flag is greater than 2 but not 10 or 15, etc
- un-zen: yet even more ways to set that integer flag
(PYTHONOPTIMIZE, -OOO, "-X opt-nodebug -X opt-noassert")
- mixed-bag -X options are less discoverable than just adding a
new command line option (like -N or -OOO)
- other downsides, I'm sure
Hmmm.... stalled again, I think.
--diana
More information about the Python-ideas
mailing list