Jonathan Fine writes:
> Sometimes a loop has multiple break commands, which have different
> purposes. So a further extension might be
> for i in items:
> LOOP_BODY
> if break left:
An if here is already valid syntax. I'm pretty sure that the parsers
can handle it. But Python statement-introducing keywords are
intentionally quite distinct for human consumption. The fact that
else and elif are similar in some ways is mitigated by the fact that
they have very similar semantics.
It's also true that the "in" and "is" operators would be somewhat
confusable, but I don't think that's as important as having quite
distinct statement keywords.
> print('exit via break left')
> elif break right:
> print('exit via break right')
> elif break:
'break' is of course already a "hard" keyword, globally reserved. But
this looks very much like
elif flag:
to me.
> print('exit via some other break')
> else:
> print('exit via StopIteration')
Finally, much of what this syntax allows is possible like this:
for i in items:
LOOP_BODY_ABOVE_BREAKS
if LEFT:
# NOTE: additional indentation here is hidden in LOOP_BODY
# in the OP.
print('exit via break left')
break;
LOOP_BODY_AMID_BREAKS
if RIGHT:
print('exit via break right')
break;
LOOP_BODY_AMID_BREAKS
if CENTER:
print('exit via some other break')
break;
LOOP_BODY_BELOW_BREAKS
else:
print('exit via StopIteration')
So the new feature is to distinguish some breaks from other breaks and
collect the action suites for breaks that have exactly the same
actions in a single place. But how often is this going to be useful?
If it *is* useful, it occurs to me that (1) this looks a lot like the
try ... except ... pattern, and (2) breaks are generally perceived as
exceptional exits from a loop. Instead of "if break [LABEL]", "except
[LABEL]" might work, although the semantic difference between labels
and exceptions might get a ton of pushback.
That said, I can't think of a time where I wanted more than one kind
of a break from a loop, let alone where some kinds existed in multiple
instances. So I'm -1 unless we see plausible use cases for the extra
power, and a before-after comparison shows a perceptible readability
improvement.
Steve
_______________________________________________
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/GF2OU3EACUIEEXZJT46CDNVXP3BF7JKW/
Code of Conduct: http://python.org/psf/codeofconduct/
