On 20/07/2020 09:56, Alex Hall wrote:
On Mon, Jul 20, 2020 at 10:36 AM Rob Cliffe via Python-ideas <python-ideas@python.org> wrote:
May I repeat:  Spelling 'if break:' and 'if not break:' rather than say
'on_break:' etc. would avoid adding new keywords.

I don't know what to do about the zero iterations case, though.

It could be that if `break` appears somewhere that an expression is expected, it becomes an expression with the value 0 or 1 (or False or True) to indicate the number of breaks that happened in the previous loop, and similarly some other bit of code involving keywords can become the number of iterations of the previous loop. This could be represented by `for`, `len(for)`, `pass`, etc. So one might write:

for x in ...:
if not pass:
elif pass == 1:
`break' becoming an expression is fine by me.

But detecting the number of iterations (however it's spelt) might be tricky.
Always counting the number of iterations would slow down *every* for/while loop - surely unacceptable.
So the compilation process must only incorporate this loop-counting when the loop is followed (after 100 lines of code??) by a reference to the loop count.

Another way would be for the first iteration (i.e. the first call of `next') to be coded separately (in the bytecode).  If the first call does not raise StopIteration, it could set a flag meaning "at least 1 iteration occurred",  But this would bloat the code, and again doesn't seem like a great idea if it applies to *every* for/while loop.

Therefore: I suggest that the proposal should be modified to just detect break or no break.  That's already progress.  And if in future someone thinks of a brilliant way of detecting zero (or N) iterations,  that can be added later.