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

[Terry Reedy]

On 5/22/2014 9:24 AM, Ned Batchelder wrote:
> On 5/22/14 2:44 AM, Terry Reedy wrote:
>> On 5/21/2014 6:59 PM, Ned Batchelder wrote:
>>
>>> If by implementation details, you mean the word "peephole", then let's
>>> remove it, and simply have a switch that disables all optimization.
>>> Rather than limiting the future of the optimizer, it will provide an
>>> escape hatch for people who would rather not have the optimizer's
>>> effects.
>>
>> The presumption of this idea is that there is a proper, canonical
>> unoptimized version of 'compiled Python'. For Python there obviously
>> is not. For CPython, there is not either. What Raymond has been saying
>> is that the output of the CPython compiler is the output of the
>> CPython compiler.

> I'd like to understand why we think the Python compiler is different in
> this regard than a C compiler.

Python is a different language. But let us not get sidetracked on that.

> When this came up 18 months ago on Python-Dev, it was part of a thread
> about adding more optimizations to CPython.  Guido said "+1" to the idea
> of being able to disable the optimizers
> (https://mail.python.org/pipermail/python-dev/2012-December/123099.html).

I read that and it is not to me exactly what his quick, top-posted '+1' 
really means. I claimed in response to Marc-Andre that CPython has 
always had an as-if rule and numerous optimizations, some of which 
cannot, realistically, be disabled. Nor would we really want to disable 
'all optimization' (as you requested in your post).

My objection to 'disable the peephole optimizer' is that it likely 
disables too much, and perhaps too little (as more is done with asts). 
Also, it seems it may add a continuing burden to a relatively small core 
developer team, which also has an stdlib to maintain.

I think we should initially focus on the ghosting of 'continue'. While 
the coverage problem can be partly solved by adding 'continue' to 
'exclude lines', that will not solve the problem of a debugger 
checkpoint not working. I think you could argue (very Pythonically ;-) 
that the total machine-time saving of ghosting 'continue' is not worth 
the extra time waste of humans. I would be happier removing that 
particular optimization than with adding machinery to make it optional.

If, as has been proposed, some or all of the peephole (code) 
optimizations were moved to the ast stage, where continue jumps are 
still distinguished by Continue nodes, it might be easier to selectively 
avoid undesirable ghosting of continue statements.

-- 
Terry Jan Reedy