<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 1:28 PM Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This looks great Brett, thanks for pushing it forward.  I think it's a<br>
perfectly natural and consistent extension to PEP 3147.<br>
<br>
Some comments inlined.<br>
<br>
On Feb 27, 2015, at 05:06 PM, Brett Cannon wrote:<br>
<br>
>Rationale<br>
>=========<br>
><br>
>  - 0: ``.pyc``<br>
>  - 1 (``-O``): ``.pyo``<br>
>  - 2 (``-OO``): ``.pyo``<br>
<br>
This is all the rationale I need. :)<br>
<br>
>The "opt-" prefix was chosen so as to provide a visual separator<br>
>from the cache tag. The placement of the optimization level after<br>
>the cache tag was chosen to preserve lexicographic sort order of<br>
>bytecode file names based on module name and cache tag which will<br>
>not vary for a single interpreter. The "opt-" prefix was chosen over<br>
>"o" so as to be somewhat self-documenting. The "opt-" prefix was<br>
>chosen over "O" so as to not have any confusion with "0" while being<br>
>so close to the interpreter version number.<br>
<br>
I get it, and the examples you include in the open questions is helpful, but I<br>
still don't like "opt-".  We'll no doubt bikeshed on this until Guido<br>
decides but looking at the examples below I'd be okay with 'O<level>'.  Did<br>
you consider 'opt<level>', e.g. imporlib.cpython-35.opt0.pyc ?<br></blockquote><div><br></div><div>Nope, and I'll think about it and at least add it as a possibility.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>Compatibility Considerations<br>
>============================<br>
<br>
Just as PEP 3147 had to make backward compatibility concessions to .pyc files<br>
living outside __pycache__ (which I think is still supported, right?)</blockquote><div><br></div><div>Unfortunately yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I think<br>
you'll have to do the same for traditional .pyo files, at least for Python<br>
3.5.  You won't have to *write* such files, but if they exist and the<br>
corresponding optimization level pyc file isn't present in __pycache__, you'll<br>
have to load them.<br>
<br>
It might in fact make sense to add some language to this PEP saying that in<br>
Python 3.6, support for old-style .pyc and .pyo files will be removed.<br></blockquote><div><br></div><div>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.</div></div></div>