On 06/08/2020 08:57, Stephen J. Turnbull 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.
Did you see Guido's post when I raised a similar object to detecting "zero iterations", where it would be unacceptable to slow down all for-loops, so they would have to be compiled differently? I wrote (in ignorance:-)):
So: You're asking that the bytecode generated for the for-loop depends on something that happens (or not) after the end of the for-loop body (which could be arbitrarily long).
I speak from ignorance, but I suspect that even with the new parser, which I am reliably informed can make the tea and implement world peace, that would be asking a lot.
Guido replied: Rest assured this is not a problem. In any case it’s the compiler, not the parser, that generates the bytecode, from the AST. The compiler always has the full AST available before it is asked to generate any bytecode. The new parser just allows more flexible syntactic constructs, esp. “soft keywords”.
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.
IMO this is a bit disingenuous: "as" can be used with "import" and with context managers with quite different semantics. "del" can be used to remove a variable binding, a sequence element, a sequence slice or a dictionary key. "not" can be used as Boolean negation or in the compound operator "not in". Whereas the new use of "except" that Matthew is proposing is very similar to its existing use (certainly conceptually, if not in the implementation details).
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 (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.
(To be clear: although I'm defending Matthew's proposal here, my preferred option is still some new syntax.)
Python-ideas mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/OVRYSB... Code of Conduct: http://python.org/psf/codeofconduct/