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