[Python-ideas] PEP 572: Statement-Local Name Bindings

[Paul Moore]

On 2 March 2018 at 14:23, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 2 March 2018 at 23:26, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> Adding "mustn't just be another way to spell name = expr" to the
>> requirements is an extra requirement - and arguably one that
>> contradicts the original requirement which was "find a way to allow
>> name = expr in expressions".
>
>
> I consider allowing the semantic equivalent of "name = expr" as part of
> arbitrary expressions to be an anti-requirement, not a requirement, for
> three reasons:
>
> 1. It means that arbitrary statements may accidentally clobber local
> variables that we care about. We used to have this for comprehension
> iteration variables, and it was so widely deplored that we broke
> compatibility with the variable overwriting behaviour in Python 3.0.
>
> 2. It means that naming a subexpression may significantly increase the
> longevity of that reference (especially in generators and coroutines).
>
> 3. It means that naming a subexpression will define a new class or module
> attribute when used in a class or module scope
>
> Folks do sometimes *ask* for these semantics, as it's the most obvious
> behaviour to ask for when it comes to naming subexpressions, but it would be
> a really bad idea to say "yes" to those requests.
>
> Chris's PEP addresses all those potential problems:
>
> 1. Statement locals explicitly avoid overwriting regular function locals
> (although they may shadow them in the current PEP - the '.name' syntax
> avoids even that)
> 2. Statement local bindings are cleared after each statement, so they only
> significantly extend the reference lifespan when used in compound statement
> headers or directly in the same statement as a yield or await. Even in
> comprehensions they'll typically be cleared on the next loop iteration.
> 3. Statement locals aren't added to locals() or globals(), so they never
> show up as module or class attributes either
>
> The eventual conclusion may still be "The proposal adds too much additional
> complexity without an adequate corresponding gain in expressiveness", but
> that complexity does have a solid rationale behind it. (Although it may be
> worth explicitly answering "Why not use the exact same semantics as 'name =
> expr'? in the PEP itself, since it's a reasonable question to ask)

OK, understood.

Yes, I think it would be worth adding that question to the PEP. I also
think it would be worth being more explicit in the body of the PEP
over how[1] the binding of statement-local names is fundamentally
different from assignment, as that certainly wasn't obvious to me, and
may not be to others (particularly people reading it with the point of
view "This satisfies my request to allow assignment in expressions").

I don't really have much more to add in that case. I don't personally
think the added complexity is justified by the benefits, but I've
already said that and it's been noted - so thanks for helping me
understand the details of the proposal better, but it hasn't changed
my view much in the end.

Paul

[1] The "why" is covered by the question you suggested.