[Import-SIG] PEP for the removal of PYO files

[Brett Cannon]

On Sat, Feb 28, 2015 at 11:50 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 28 February 2015 at 03:06, Brett Cannon <bcannon at gmail.com> wrote:
> > Here is my proposed PEP to drop .pyo files from Python. Thanks to Barry's
> > work in PEP 3147 this really shouldn't have much impact on user's code
> (then
> > again, bytecode files are basically an implementation detail so it
> shouldn't
> > impact hardly anyone directly).
>
> Some specific technical questions/suggestions:
>
> * Can we make "opt-0" implied so normal pyc file names don't change at all?
>

Sure, but why specifically? EIBTI makes me not want to have some optional
bit in the file name just make someone's life who didn't use
cache_from_source() a little easier.


>
> * I'd like to see a description of the impact on compileall (which may
> be "no impact", but I'd like the PEP to explicitly say that if so)
>

Are you talking about the command-line interface? If so then no, it makes
no special difference beyond the fact that .pyo files won't be put in the
legacy locations if you run the interpreter with -O and -OO.


>
> > One thing I would appreciate is if people have more motivation for this.
> > While the maintainer of importlib in me wants to see this happen, the
> core
> > developer in me thinks the arguments are a little weak. So if people can
> > provide more reasons why this is a good thing that would be appreciated.
>
> For that aspect, I'd suggest pitching the PEP as aiming primarily at
> separating the two optimisation levels (so stripped PYO files don't
> overwrite normal ones) and then simply eliminating the pyo extension
> entirely as being redundant since the new mechanism will also make it
> possible to distinguish optimised files from unoptimised ones.
>
> The first is the user facing benefit of the change (e.g. it lets us
> precompile all three levels in distro packages), while the latter is
> just a nice import maintainer facing side-effect.
>

I'll add a sentence mentioning it allows all optimization levels to be
compiled and available at once.


>
> This perspective would likely be further strengthened if the "opt-0"
> case were taken as the implied default rather than being explicit in
> the filename.
>

Is that really so important? When was the last time you looked in a
__pycache__ directory?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20150228/b42244a1/attachment.html>