[Python-Dev] The `for y in [x]` idiom in comprehensions

[Chris Angelico]

On Mon, Feb 26, 2018 at 8:00 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 26 February 2018 at 01:08, Chris Angelico <rosuav at gmail.com> wrote:
>>
>> Speaking as a C programmer who's quite happy to write code like "while
>> ((var = func()) != sentinel)", I wouldn't object to this coming up in
>> Python; the "as name" syntax has the huge advantage over C's syntax in
>> that you can't accidentally leave off one equals sign and get the
>> wrong behaviour. But I know that a lot of people dislike this at a
>> more fundamental level.
>>
>> If someone wants to push for this, I think it probably needs a PEP -
>> it's a point that comes up periodically. I don't think it's ever had a
>> PEP written about it, but it's a bit hard to search for; maybe someone
>> else knows off hand?
>
>
> PEP 3150 is the most closely related PEP we have at the moment (and that
> only works for simple statements, since it relies on using a trailing block
> to name the subexpressions).
>
> The "(EXPR as NAME)" syntax comes up periodically, especially in the context
> of while loops (where it would allow a direct translation of C-style
> embedded assignment idioms).
>
> In addition to the potential confusion for "with (EXPR as NAME):" vs "with
> EXPR as NAME:" (and the similar ambiguity for "except" clauses), some other
> major questions to be resolved are:
>
> * are statement locals in a class namespace turned into attributes on the
> resulting class? (it would be more useful if they weren't)
> * are statement locals in a module namespace turned into attributes on the
> resulting module? (it would be more useful if they weren't)
> * are statement locals in a function/generator/coroutine namespace kept
> alive until the entire call terminates? (it would be more useful if they
> weren't)
> * do currently defined statement locals appear in calls to locals() or in
> frame.f_locals?
> * can lexically nested scopes see names bound this way? (a lot of complex
> name resolution problems disappear if they can't, plus you get a clearer
> distinction between these and regular function locals)
>
> To be interesting enough to potentially be worthy of syntax, I think name
> bindings written this way would need to be truly statement local:
>
> * reference is released at the end of the statement (whether simple or
> compound)
> * no ability to close over them (this goes hand in hand with eagerly
> dropping the reference)
> * we play name mangling games and/or use different opcodes to avoid
> overwriting regular function locals and to avoid appearing in locals()

Definitely possible. I wish I still had the POC patch that I put
together a while ago that created block-local variables from 'as'
bindings in except and with statements, but it got lost in a hard
drive crash (because, at the time, I didn't think it was useful for
anything more than "haha, isn't that cute"). Will see if I can
recreate it.

ChrisA