I'm not happy with the direction this is taking. I would prefer an approach that *first* implements the minimal thing (an internal flag, set by an environment variable, to disable the peephole optimizer) and *then* perhaps revisits the greater UI for specifying optimization levels and the consequences this has for pyc/pyo files.

I would also like to remind people the reason why there are separate pyc and pyo files: they are separate to support precompilation of the standard library and installed 3rd party packages for different optimization levels.
 While it may be okay for a developer that their pyc files all get invalidated when they change the optimization level, the stdlib and site-packages may require root access to write, so if your optimization level means you have to ignore the precompiled stdlib or site packages, that would be a major drag on your startup time (and memory usage will also spike at import time, since the AST is rather large).

Looking at my own (frequent) use of coverage.py, I would be totally fine if disabling peephole optimization only affected my app's code, and kept using the precompiled stdlib. (How exactly this would work is left as an exercise for the reader.)


On Fri, May 23, 2014 at 9:33 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 23 May 2014 19:30, Victor Stinner <victor.stinner@gmail.com> wrote:
> 2014-05-23 11:11 GMT+02:00 Nick Coghlan <ncoghlan@gmail.com>:
>> Given how far away 3.5 is, I'd actually be interested in seeing a full
>> write-up of Eric's proposal, comparing it to the "let's just add some more
>> technical debt to the pile" -X option based approach.
>
> The discussion in now splitted in 4 places: 3 threads on this mailing
> list, 1 issue in the bug tracker. And there are some old discussions
> on python-dev.
>
> It's maybe time to use the power of the PEP process to summarize this
> in a clear document? (Write a PEP.)

Yes, I think so. One key thing this discussion made me realise is that
we haven't taken a serious look at the compilation behaviour since PEP
3147 was implemented. The introduction of the cache tag and the
source<->cache conversion functions provides an opportunity to
actually clean up the handling of the different optimisation levels,
and potentially make docstring stripping an independent setting.

It may be that the end result of that process is to declare "-X
nopeephole" a good enough solution and proceed with implementing that.
I just think it's worth exploring what would be involved in fixing
things properly before making a decision.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



--
--Guido van Rossum (python.org/~guido)