Thank you Rob, for your contribution. I find it very helpful. You've raised important implementation questions. Regarding the no-iterations case. Suppose we have for i in items: loop_body case: zero: print('no items to process') In this case, the Python compiler knows that the post-iteration block contains a 'zero:' statement. And in other cases it knows that it does not. So why not have the compiler produce bytecode that records this fact. (This could be done by providing an additional bytecode, or if there's room adding a flag to an existing bytecode.) Depending on how we choose to implement, if we wish we could keep both the bytecode and interpreter code exactly the same, for the currently allowed post-iteration blocks. I apologize that it wasn't clear to you from my example code, that for example we allow any identifier as the 'label argument' in a break statement. As in break error_1 break error_2 break time_out The compiler can and I think should ensure that all labels in the post-iteration block occur in the iteration block. And a code analysis code aka linter should warn about unreachable code. This unreachable code should, of course, not generate any bytecode. Thank you again for your comment. I hope this helps. -- Jonathan