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.

Steve

(To be clear: although I'm defending Matthew's proposal here, my preferred option is still some new syntax.)

_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OVRYSB4WRAYWSD2UGUS5MZHQ2PCZLUJR/
Code of Conduct: http://python.org/psf/codeofconduct/