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

[Rob Cliffe]

On 01/03/2018 06:47, Chris Angelico wrote:
>
>> This is the kind of ambiguity of intent that goes away if statement locals
>> are made syntactically distinct in addition to being semantically distinct:
>>
>>    .a = (2 as .a) # Syntax error (persistent bindings can't target statement
>> locals)
>>    a = (2 as .a) # Binds both ".a" (ephemerally) and "a" (persistently) to
>> "2"
>>    .a[b] = (x as .a) # Syntax error (persistent bindings can't target
>> statement locals)
>>    b[.a] = (x as .a) # LHS references .a
>>    .a[b].c = (x as .a) # Syntax error (persistent bindings can't target
>> statement locals)
>>    b[.a].c = (x as .a) # LHS references .a
-1.  Too much grit!  And I think trying to put the dots in the right 
places would be a frequent source of mistakes (albeit mistakes that 
could usually be corrected quickly).
> Okay. I think I have the solution, then. One of two options:
>
> 1) SLNBs are not permitted as assignment (incl augassign) targets.
> Doing so is a SyntaxError.
> 2) SLNBs are ignored when compiling assignment targets. Doing so will
> bind to the "real" name.
>
> Using an SLNB to subscript another object is perfectly acceptable, as
> that's simply referencing. The only case that might slip between the
> cracks is "a[b].c" which technically is looking up a[b] and only
> assigning to *that* object (for instance, if 'a' is a tuple and 'b' is
> zero, it's perfectly legal to write "a[b].c = 1" even though tuples
> are immutable). Other than that, the intention given in all your
> examples would be sustained.
>
> Which of the two is preferable? I'm thinking of going with option 2,
> but there are arguments on both sides.
>
>
+1 to one of these two options.
+1 to choosing 2).  I think it's easier to understand and explain 
"temporary variables do not apply to the LHS of an assignment statement".
(Incidentally, when in an earlier post I suggested that Expression LNBs 
might be better than Statement LNBs, I didn't realise that a temporary 
variable created in the first line of a suite ("if", "while" etc.) 
remained in scope for the rest of that suite.  That seems (on balance) 
like a Good Thing, and a lot of the rationale for SLNBs.  But I didn't 
like a temporary variable applying to the LHS of as assignment.  So, 
with the above change to assignment statements, I am now happy about SLNBs.)

Rob Cliffe