Optimization levels embedded in .pyo file names?

Something I have been thinking about is whether we should start embedding
the -O option into the bytecode file name, e.g., foo.cpython-35.O2.pyo (the
O could also be lowercase if people preferred). It would save people from
making the mistake of executing their code with a mixture of -O and -OO. It
also avoids having to regenerate all of your .pyo whenever you want to
tweak which optimization level you are running at. And finally, if we make
importlib.cache_from_source() take an optional `optimization` argument then
people could even start specifying their own optimizations and have them
saved to their own .pyo files (with the caveat that some restrictions be
placed on the value, such as it has pass str.isalnum()).

As for importlib.cache_from_source() and it's debug_override parameter, I
would say we should lean on bools being ints and simply use its argument as
the optimization level (while it gets phased out).

I would love to even go so far as to say that we drop the .pyo file
extension and make what has normally been .pyc files be .O0.pyc and what
has usually been -O and -OO be .O1.pyc and .O2.pyc, but my suspicion is
that it might break too much code in a transition and so .pyc stays as such
and then .O1.pyo and .O2.pyo comes into existence from the stdlib.

By doing this the last bit of runtime state that influences compiling and
importing code will somehow be exposed in bytecode files. I don't think it
should be embedded in the bytecode file header as this has nothing to do
with the validity of the bytecode compared to the source, just whether it
should be run with the current interpreter (much like the interpreter name).

Thoughts?

_______________________________________________
Import-SIG mailing list
[email protected]
https://mail.python.org/mailman/listinfo/import-sig