[Python-ideas] For/in/as syntax

[Brice PARENT]

>
> * 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?
I don't know much about the specifics on how it works behind the scenes, 
and even less about other implementations of the language, so I just 
give my opinions on the usage and the benefits of such a syntax. 
However, I'm not sure the object should be constructed and fed for every 
loop usage. It should probably only be instanciated if explicitly asked 
by the coder (by the use of "as loop_name"). I don't know what happens 
to the caught exceptions when they are not set to a variable (using 
except ExceptionType as e), but I think we would be in a similar case, 
only, if the object is instanciated, its states would evolve each time 
the loop starts another iteration.
>
> * 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).
I don't really understand what this means, as I'm not aware of how those 
things work in the background. But it would create an object and feed it 
to the variable, yes. I guess it would be magical in the sense it's not 
the habitual way of constructing an object. But it's what we're already 
used to with "as". When we use a context manager, like "with 
MyPersonalStream() as my_stream:", my_stream is not an object of type 
"MyPersonalStream" that has been built using the constructor, but the 
return of __enter__() (at least, it's what I understood), and the 
MyPersonalStream instance is somewhere else waiting for its closing 
fate. And when catching an exception, we feed a new variable with an 
object created somewhere-else-in-the-code, not with a classic 
instanciation. So this behaviour, obtaining an object created somewhere 
else and not explicitly, seems logical with the other uses of "as", IMHO.
>
> * 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).
This solution, besides having been explicitly rejected by Guido himself, 
brings two functionalities that are part of the proposal, but are not 
its main purpose, which is having the object itself. Allowing to break 
and continue from it are just things that it could bring to us, but 
there are countless things it could also bring (not all of them being 
good ideas, of course), like the .skip() and the properties I mentioned, 
but we could discuss about some methods like forloop.reset(), 
forloop.is_first_iteration() which is just of shortcut to (forloop.count 
== 0), forloop.is_last_iteration() (which would probably only be 
available on fixed-length iterables), and probably many other things to 
play with the sequencing of the loop.
>
> 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 ;)).
I have no clue on the implementation side, and I'm pretty sure such a 
big change couldn't ever be problem-free, I'm just convinced it could 
bring a lot of control and readability on the user side.

Brice