Nested scopes, and augmented assignment

[Antoon Pardon]

On 2006-07-07, Terry Reedy <tjreedy at udel.edu> wrote:
>
> "Antoon Pardon" <apardon at forel.vub.ac.be> wrote in message 
> news:slrneapmfr.at1.apardon at rcpc42.vub.ac.be...
>> And if  Nested variables are harmfull,
>
> I don't know if anyone said that they were, but Guido obviously does not 
> think so, or he would not have added them.  So skip that.
>
>> what is then the big difference between rebinding them and mutating them
>
> A variable is a name.  Name can be rebound (or maybe not) but they cannot 
> be mutated.  Only objects (with mutation methods) can be mutated.  In other 
> words, binding is a namespace action and mutation is an objectspace action. 
> In Python, at least, the difference is fundamental.
>
> Or, in other other words, do not be fooled by the convenient but incorrect 
> abbreviated phrase 'mutate a nested variable'.

I'm not fooled by that phrase. I just think the mutate vs rebind
explanation is not complete.

If we have two statements "a = b" and "c.d = b" the fact that a is being
rebound while c is mutated doesn't explain why we allow c to be searched
out of the local scope.

By only stating that the first statement is a rebinding and the second
is a mutation and that this is a fundamental difference in python you
seem to suggest that this fundamental differenence implies this
difference in searching scopes. Python could have made the choice
that in an assignment the variable on the left side was always to
be searched in local space so that code like the following would
throw: UnboundLocalError: local variable 'c' referenced before assignment

c = SomeObject
def f():
  c.a = 5

Now I'm not arguing python should have made this choice. But the
possibility shows IMO this has more to do with search policies
of names than with the distinction between a rebinding and a mutation.

AFAIK when nested scopes where introduced everyone agreed that scopes
had to have access to outer scopes. There were voices that supported
allowing a rebinding in an outer scope but no consensus on how to
do this was reached, so this possibility was dropped. So we can't
rebind an outer scope variable but we can mutate such a variable
because for mutation we only need access.

>> I understand that python evolved and that this sometimes results
>> in things that in hindsight could have been done better.
>
> So does Guido.  That is one explicit reason he gave for not choosing any of 
> the nunerous proposals for the syntax and semantics of nested scope write 
> access.  In the face of anti-consensus among the developers and no 
> particular personal preference, he decided, "Better to wait than roll the 
> dice and make the wrong, hard to reverse, choice now".  (Paraphrased quote)
>
>>I have to wonder if someone really thought this through at design time
>
> Giving the actual history of, if anything, too many people thinking too 
> many different thoughts, this is almost funny.

Maybe I didn't made myself clear enough, but I never meant to imply
people hadn't thought thouroughly about this. If I gave you this
impression I appologize. What I was wondering about was that those
that had thought about it, would have reached a certain conclusion
that seemed suggested.

> Recently however, Guido has rejected most proposals to focus attention on 
> just a few variations and possibly gain a consensus.  So I think there is 
> at least half a chance that some sort of nested scope write access will 
> appear in 2.6 or 3.0.

Well I have browsed the discussion, which is why I react so lately to
this, and there is one thing I wonder about. As far as I can see no
suggestion removes the difference in the default search. The following
code will still work and won't need an outer statement. (or global,
nonlocal or whatever it will be)

c = SomeObject
def f():
  c.a = 5

I don say they have to change this, but since it seemed decided this
was a python3k thing, i think the question deserved to be raised.

But I'm glad with this turn of events anyhow.

Just my 2 cent.

-- 
Antoon Pardon