[Import-SIG] Optimization levels embedded in .pyo file names?

[Brett Cannon]

On Fri Jan 30 2015 at 7:02:04 PM Eric Snow <ericsnowcurrently at gmail.com>
wrote:

> On Fri, Jan 30, 2015 at 2:46 PM, Barry Warsaw <barry at python.org> wrote:
> > On Jan 30, 2015, at 07:28 PM, Brett Cannon wrote:
> >
> >>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
> >
> > +1 - we've had some trouble in the past in Debian with the name
> collisions on
> > .pyo for the different optimization levels.
> >
> >>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.
> >
> > I actually *would* go so far.  I thought about it during the PEP 3147
> > time frame but it was out-of-scope at the time.  A transition period
> might be
> > necessary (and/or a switch to choose) but I think it's a good end state.
>

Assuming no one flips out about writing a bunch of files we could write
files using the new and old file paths (or symlink the old paths to the
new, but that seems to be asking for trouble on some OS that doesn't
support them but maybe I'm being paranoid). That way people who construct
file paths manually can still read the old paths but those who use
cache_from_source() will get the new paths automatically (although
override_debug will be a little wonky but nothing horrible in the New
World). And anyone who really doesn't want all of those files written can
run with sys.dont_write_bytecode set to True after byte-compiling their
code.

This "multiple bytecode files for the same thing" approach might spike stat
calls since we would have to check which path is newer in case someone
edited the old path out-of-band, but it shouldn't be too bad (it will
obviously startup time will have to be measured).


>
> +1 to all of it. :)
>

Since everyone seems to think it's a good idea I will write up a PEP with
the end goal of going all the way with .pyc (probably on Friday).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20150131/a3b04755/attachment.html>