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!