Re: Optimization levels embedded in .pyo file names?
Eric Snow <[email protected]> Fri, 30 Jan 2015 17:01:58 -0700
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <CALFfu7ARZ4dDS_6=cq-tatK+VRifnQOO=2cs3V4GWuRfLXWMJA@mail.gmail.com> |
On Fri, Jan 30, 2015 at 2:46 PM, Barry Warsaw <[email protected]> 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. +1 to all of it. :) -eric