On 5/21/14 3:44 PM, Raymond Hettinger 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).
Yes, this could mean an increased testing burden. But that scale
horizontally, and will not require a large amount of engineering
work. Besides, what better way to test the optimizer?
* 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.
I'm perfectly happy to remove the word "peephole" from the feature.
If we expect the set of optimizations to grow in the future, then we
can expect that more cases of code analysis will be misled by
optimizations. All the more reason to establish a way now that will
disable all optimizations.
* 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.
I don't think you should dismiss real users' concerns as a
curiosity. We already have -X as a way to provide
implementation-specific switches, I'm not sure why the CPython-only
nature of this is an issue?
* As the other implementations of Python continue to develop,
I don't think we should tie their hands with respect to code
generation.
This proposal only applies to CPython.
* 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.
I'm happy to remove the word "peephole". I think a way to disable
optimization is useful. I've heard the concern from a number of
coverage.py users. If as we all think, optimizations will expand in
CPython, then the number of mis-diagnosed code problems will grow.
--Ned.
* 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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/