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