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

Chris Angelico rosuav at gmail.com
Thu Mar 1 01:40:51 EST 2018


On Thu, Mar 1, 2018 at 3:31 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 28 February 2018 at 08:27, Chris Angelico <rosuav at gmail.com> wrote:
>> 2. The current implementation [1] implements statement-local names using
>>    a special (and mostly-invisible) name mangling.  This works perfectly
>>    inside functions (including list comprehensions), but not at top
>>    level.  Is this a serious limitation?  Is it confusing?
>
>
> It isn't clear to me from the current PEP what the intended lifecycle of the
> bound names actually is, especially for compound statements.

I think you're looking at an old version of the PEP, but that's kinda
gonna happen on the first day of a hot topic :) But to remove all
confusion, I've now added a section clarifying execution order, using
several of your examples.

>     x = (expr as y)
>     assert x == y # Does this pass? Or raise NameError for 'y'?

NameError. The SLNB is gone at end of line.

>     if (condition as c):
>         assert c # Does this pass? Or raise NameError for 'c'?
>     else:
>         assert not c # Does this pass? Or raise NameError for 'c'?
>     assert c or not c # Does this pass? Or raise NameError for 'c'?

c is available in the indented blocks, and is gone once the entire
'if/else' block is done.

>     class C:
>         x = (True as y)
>     assert C.y # Does this pass? Or raise AttributeError for 'y'?

That'll raise. (At least, according to the specification and intent.
The reference implementation may be lagging a bit.)

> I think it would also be worth explicitly considering a syntactic variant
> that requires statement local references to be explicitly disambiguated from
> regular variable names by way of a leading dot:
>
>     result = [[(f(x) as .y), .y] for x in range(5)]
>
> [chomp]
>
> Since ".NAME" is illegal for both variable and attribute names, this makes
> the fact statement locals are a distinct namespace visible to readers as
> well as to the compiler, and also reduces the syntactic ambiguity in with
> statements and exception handlers.

I've mentioned this in the alternate syntaxes, but I don't like having
to state a variable's scope in its name. Python doesn't force us to
adorn all global names with a character, and the difference between
function-local and statement-local is generally less important than
the difference between global and function-local. But it IS a viable
syntax, and I'm saying so in the PEP.

Thanks for the feedback! Much appreciated.

ChrisA


More information about the Python-ideas mailing list