On 21.05.2014 14:13, Steven D'Aprano wrote:
On Wed, May 21, 2014 at 07:05:49AM -0400, Ned Batchelder wrote:
** The problem
A long-standing problem with CPython is that the peephole optimizer cannot be completely disabled. Normally, peephole optimization is a good thing, it improves execution speed. But in some situations, like coverage testing, it's more important to be able to reason about the code's execution. I propose that we add a way to completely disable the optimizer.
I'm not sure whether this is an argument for or against your proposal, but the continue statement shown below is *not* dead code and should not be optimized out. The assert fails if you remove the continue statement.
I don't have 3.4 on this machine to test with, but using 3.3, I can see no evidence that `continue` is optimized away.
The logical continue is still there -- what happens is that the optimizer rewrites the `else` jump at the preceding `if` condition, which would normally point at the `continue` statement, to the beginning of the loop, because it would be a jump (to the continue) to a jump (to the for loop header). Thus, the actual continue statement is not reached, but logically the code does the same, because the only way continue would have been reached was transformed to a continue itself.
Later in your post, you say:
It's true: the byte code for that statement [the continue] is not executed, because the peephole optimizer has removed the jump to the jump.
But that cannot be true, because if it were, the assertion would fail. Here's your code again:
To demonstrate the problem, here is continue.py:
a = b = c = 0 for n in range(100): if n % 2: if n % 4: a += 1 continue else: b += 1 c += 1 assert a == 50 and b == 50 and c == 50
If the continue were not executed, c would equal 100 and the assertion would fail. Have I misunderstood something?
(By the way, as given, your indents are inconsistent: some are 4 spaces and some are 5.)