Re: PEP for the removal of PYO files
Brett Cannon <[email protected]> Sat, 28 Feb 2015 21:08:50 +0000
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <CAP1=2W7+37R2Ktq=4xPJOMEiHMrswOQ7X1dqK=vK5F+ax+CmzA@mail.gmail.com> |
On Sat, Feb 28, 2015 at 11:50 AM Nick Coghlan <[email protected]> wrote: > On 28 February 2015 at 03:06, Brett Cannon <[email protected]> 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? _______________________________________________ Import-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/import-sig