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