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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
