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

Nick Coghlan ncoghlan at gmail.com
Fri Mar 2 09:23:16 EST 2018


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)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180303/bbc1f6d4/attachment.html>


More information about the Python-ideas mailing list