On May 23, 2014, at 12:49 PM, Guido van Rossum <guido@python.org> wrote:
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 agree with this I think.
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.
Sadly enough it doesn’t go far enough since you can’t have (as far as I know) a .pyo for both -O and -OO. Perhaps the PEP isn’t the worst idea in order to make all of that work with the __pycache__ directories and the pyc tagging.
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) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA