Some pros and cons that occur to me (I may be biased, YMMV):
(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).
(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.
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.
for x in iterable:...
for x in iterable:...except Exception:raise
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.
It might be possible to save that level of indentation with this
try for elem in iterable:
except SomeException as e:
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 (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.
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.