
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