Thank you both for the feedback.

Some pros and cons that occur to me (I may be biased, YMMV):
Pros:
    (1) It can cleanly separate the handling of break-type exceptions and other exceptions, if needed.
    (2) It actually clarifies what the dreaded "else" means!
    (3) it allows you to group your "break" cases using exception subclasses (although this is probably OTT for most use cases).
Cons:
    (4) It's more work. You have to decide what exceptions to use and (most likely) create them.

    (5) It adds the runtime overhead of setting up the "try" and possibly raising the exception.
    (6) Putting (implicitly) try...except around a possibly long for-suite feels bad somehow, even though it wouldn't catch other unwanted exceptions.
    (7) It does not catch the "zero iterations" case.

It is possible that 4 and 7 may be fixed by adding 2 new Exception subclasses, e.g. `BreakException`, which would "replace" break although using break would still be possible, and `NoIterationException` (though this may not be the cleanest approach). The question then becomes what to do with these when there is no `except`. At the sacrifice of automatically breaking out of multiple loops, they could be silently ignored unless caught explicitly?

I do not know well enough how the python interpreter sets up `try-except` blocks to realistically respond to 5 and 6 but I can indeed see these being sticking points.

On Thu, 6 Aug 2020 at 08:57, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

Mathew Elman writes:

> Being able to break multiple loops and having "labelled" breaks
> would be achievable using `except`, i.e. adding `except` to the
> loop statements before `else` like this:

This would certainly be consistent with the existing use of the except
keyword, unlike the proposal to have it take both exceptions (in 'try'
statements) and break labels (in 'for' and 'while' statements).

However, we would probably not want to burden all loops with the
exception-handling machinery, so the compiler would have to do some
hacky backtracking (I doubt that the arbitrary lookahead needed to
handle "maybe we got some except clauses coming?" during parsing would
be acceptable) and fill that in *after* recognizing that there are
except clauses in this for statement.

Would it be so bad to simply wrap for loops with except clauses automatically that can be clobbered or not?

e.g.

for x in iterable:
...

really does something like this

try:

    for x in iterable:
        ...
except Exception:
    raise

Meaning that it doesn't need to wait to see if it does and backtrace but can just trust that there will be the default reraise? Apologies if this is a stupid question.

Second, generally Python tries to avoid overloading keywords with
multiple semantics. The potential for confusion and misunderstanding
of "except" (which I've suggested myself and now dislike) is pretty
large I think.

I am not sure I follow you here since the `except` is being used in the same way as in `try...except` so I wouldn't expect a high potential for confusion, although I suppose that is, ironically, the same line of thinking as with `for...else`.

It might be possible to save that level of indentation with this
syntax:

try for elem in iterable:
...
if should_break(elem):
raise SomeException
except SomeException as e:
handle_break_behaviour(e)
else:
print("Did not break")

(and I suppose you could do the same for any control flow statement,
although I'm not sure offhand that the various keywords are 100%
disjoint -- that would need to be checked). But I don't think it's
worth it. I don't see enough benefits from this mixing of try and for
to make it worth the complexity.

I agree that this seems to add some complexity but I actually like this a lot. It would surely also address the issue of the parser knowing it should be looking for exceptions or not?

> I (and others) have suggested this before and no one has said it's a
> *bad *option,

It is, though, for the reasons above as well as the reasons Rob gives
in his parallel followup.

Thank you, I appreciate it at least being addressed!

Notice:
This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.

If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.

References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.