[Python-ideas] For/in/as syntax

[Erik]

On 03/03/17 19:02, Alexandre Brault wrote:
> I believe what Matthias is hoping for is an equivalent of Java's named
> break feature. Breaking out of an outer loop implicitly breaks out of
> all inner loops

Yes, and although I think making this a runtime object is an interesting 
thought (in terms of perhaps allowing other funky stuff to be 
implemented by a custom object, in line with Python's general dynamic 
ethos), I think that it should perhaps be considered a lexer/parser 
level thing only.

* Creating a real object at runtime for each loop which needs to be the 
target of a non-inner break or continue is quite a large overhead. How 
would this affect Python variants other than CPython?

* For anything "funky" (my words, not yours ;)), there needs to be a way 
of creating a custom loop object - what would the syntax for that be? A 
callable needs to be invoked as well as the name bound (the current 
suggestion just binds a name to some magical object that appears from 
somewhere).

* If nothing "funky" needs to be done then why not just make the whole 
thing syntax-only and have no real object, by making the 'as' name a 
parser-only token which is only valid as the optional subject of a break 
or continue statement:

     for foo in bar as LABEL:
         . # (a)
         .
         for spam in ham:
             .
             .
             if eggs(spam):
                 continue LABEL
             .
             .
             if not frob(spam):
                 break LABEL
     # (b)

(a) is the code generator's implied 'continue' target for the LABEL loop.
(b) is the code generator's implied 'break' target for the LABEL loop.

I'm not saying that's a great solution either. It's probably not an 
option as there is now something that looks like a bound name but is not 
actually available at runtime - the following would not work:

   for foo in bar as LABEL:
       print(dir(LABEL))

(and presumably that is part of the reason why the proposal is the way 
it is).

I'm generally +0 on the concept (it might be nice, but I'm not sure 
either the original proposal or what I mention above are particularly 
problem-free ;)).

E.