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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/QN6VMQTTQVJGUF6I6C6TEMUS57677VVZ/
Code of Conduct: http://python.org/psf/codeofconduct/
