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:-)):
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
(which could be arbitrarily long).
speak from ignorance, but I suspect that even with the new parser,
which I am reliably informed can make the tea and implement world
that would be asking a lot.
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”.
IMO this is a bit disingenuous:
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.
"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
(To be clear: although I'm defending Matthew's proposal here, my
preferred option is still some new syntax.)
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.
Python-ideas mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/OVRYSB4WRAYWSD2UGUS5MZHQ2PCZLUJR/
Code of Conduct: http://python.org/psf/codeofconduct/