[Python-ideas] Python-ideas Digest, Vol 90, Issue 30

[Raymond Hettinger]

On May 21, 2014, at 1:21 PM, python-ideas-request at python.org wrote:

>   I propose that we add a way to completely disable the 
> optimizer.

I think this opens a can of worms that is better left closed.

* We will have to start running tests both with and without the switch
turned on for example (because you're exposing yet another way to
run Python with different code).

* Over time, I expect that some of the functionality of the peepholer
is going to be moved upstream into AST transformations you will
have even less ability switch something on-and-off. 

* The code in-place has been in the code for over a decade and
the tracker item has languished for years.  That provides some
evidence that the "need" here is very small.

* I sympathize with "there is an irritating dimple in coverage.py"
but that hasn't actually impaired its usability beyond creating a
curiosity.  Using that a reason to add a new CPython-only
command-line switch seems like having the tail wag the dog.

* As the other implementations of Python continue to develop,
I don't think we should tie their hands with respect to code
generation.

* Ideally, the peepholer should be thought of as part of the code
generation.  As compilation improves over time, it should start
to generate the same code as we're getting now.  It probably
isn't wise to expose the implementation detail that the constant
folding and jump tweaks are done in a separate second pass.

* Mostly, I don't want to open a new crack in the Python veneer
where people are switching on and off two different streams of
code generation (currently, there is one way to do it).  I can't
fully articulate my instincts here, but I think we'll regret opening
this door when we didn't have to.

That being said, I know how the politics of python-ideas works
and I expect that my thoughts on the subject will quickly get
buried by a discussion of which lettercode should be used for the
command-line switch.

Hopefully, some readers will focus on the question of whether
it is worth it.   Others might look at ways to improve the existing
code (without an off-switch) so that the continue-statement
jump-to-jump shows-up in your coverage tool.

IMO, adding a new command-line switch is a big deal (we should
do it very infrequently, limit it to things with a big payoff, and 
think about whether there are any downsides).  Personally, I don't
see any big wins here and have a sense that there are downsides
that would make us regret exposing alternate code generation.


Raymond




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140521/598f805a/attachment.html>