Re: PEP for the removal of PYO files
Brett Cannon <[email protected]> Fri, 27 Feb 2015 19:40:08 +0000
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <CAP1=2W6vSwD8MsJbqd7oB_8LOwzkEbrQFbCDU+fdZg8bsU5rJQ@mail.gmail.com> |
On Fri, Feb 27, 2015 at 2:28 PM Donald Stufft <[email protected]> wrote: > On Feb 27, 2015, at 2:26 PM, Brett Cannon <[email protected]> wrote: > > > > On Fri, Feb 27, 2015 at 1:28 PM Barry Warsaw <[email protected]> wrote: > >> This looks great Brett, thanks for pushing it forward. I think it's a >> perfectly natural and consistent extension to PEP 3147. >> >> Some comments inlined. >> >> On Feb 27, 2015, at 05:06 PM, Brett Cannon wrote: >> >> >Rationale >> >========= >> > >> > - 0: ``.pyc`` >> > - 1 (``-O``): ``.pyo`` >> > - 2 (``-OO``): ``.pyo`` >> >> This is all the rationale I need. :) >> >> >The "opt-" prefix was chosen so as to provide a visual separator >> >from the cache tag. The placement of the optimization level after >> >the cache tag was chosen to preserve lexicographic sort order of >> >bytecode file names based on module name and cache tag which will >> >not vary for a single interpreter. The "opt-" prefix was chosen over >> >"o" so as to be somewhat self-documenting. The "opt-" prefix was >> >chosen over "O" so as to not have any confusion with "0" while being >> >so close to the interpreter version number. >> >> I get it, and the examples you include in the open questions is helpful, >> but I >> still don't like "opt-". We'll no doubt bikeshed on this until Guido >> decides but looking at the examples below I'd be okay with 'O<level>'. >> Did >> you consider 'opt<level>', e.g. imporlib.cpython-35.opt0.pyc ? >> > > Nope, and I'll think about it and at least add it as a possibility. > > >> >> >Compatibility Considerations >> >============================ >> >> Just as PEP 3147 had to make backward compatibility concessions to .pyc >> files >> living outside __pycache__ (which I think is still supported, right?) > > > Unfortunately yes. > > >> I think >> you'll have to do the same for traditional .pyo files, at least for Python >> 3.5. You won't have to *write* such files, but if they exist and the >> corresponding optimization level pyc file isn't present in __pycache__, >> you'll >> have to load them. >> >> It might in fact make sense to add some language to this PEP saying that >> in >> Python 3.6, support for old-style .pyc and .pyo files will be removed. >> > > Ah, but you see the magic number changed in Python 3.5 for matrix > multiplication, so pre-existing .pyo files won't even load, so they will > have to be regenerated regardless. I will mention that in the PEP. > > _______________________________________________ > Import-SIG mailing list > [email protected] > https://mail.python.org/mailman/listinfo/import-sig > > > Some people ship .pyc only code, do people also ship .pyo only code? > Definitely possible as is shipping both .pyc and .pyo files. _______________________________________________ Import-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/import-sig