[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