[Python-ideas] Disable all peephole optimizations

[Guido van Rossum]

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 at gmail.com> wrote:

> On 23 May 2014 19:30, Victor Stinner <victor.stinner at gmail.com> wrote:
> > 2014-05-23 11:11 GMT+02:00 Nick Coghlan <ncoghlan at 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 at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140523/c8f26531/attachment-0001.html>