[Python-ideas] Python-ideas Digest, Vol 90, Issue 30
Ned Batchelder
ned at nedbatchelder.com
Thu May 22 00:51:41 CEST 2014
On 5/21/14 3:44 PM, Raymond Hettinger wrote:
>
> On May 21, 2014, at 1:21 PM, python-ideas-request at python.org
> <mailto: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).
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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140521/87c5b5b2/attachment-0001.html>
More information about the Python-ideas
mailing list