Re: PEP for the removal of PYO files

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 ?

>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?) 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.

Cheers,
-Barry