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

Brett Cannon bcannon at gmail.com
Sat Feb 28 22:08:50 CET 2015

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>

More information about the Import-SIG mailing list