Nested scopes, and augmented assignment

[Antoon Pardon]

This is probably my last response to you in this thread. My impression
is that for the moment nothing productive can come from this exchange.
I have the feeling that you are not reading so much with the interntion
of understanding what I want to say, but with the intention of
confirming your suspition that I just don't have a clue.

It seems this is turing into some competition where I have
somehow to defend my understanding of python an you trying to
show how little I really understand. Since I don't feel the
need to prove myself here, I will simply bow out.

On 2006-07-09, Piet van Oostrum <piet at cs.uu.nl> wrote:
>>>>>> Antoon Pardon <apardon at forel.vub.ac.be> (AP) wrote:
>
>>AP> When someone gets confused over the difference between rebinding or
>>AP> mutating a variable on an intermediate scope, the explanation he
>>AP> mostly seems to get boils down to: one is rebinding, the other is
>>AP> mutation, this is a fundametal difference in python.
>
>>AP> My impression is that they seem to say that the fundamental difference
>>AP> between mutation and rebinding implies the specific behaviour python
>>AP> has now. IMO this explanation is incomplete. The python developers
>>AP> could have chosen that a line like 'c.a = ...' would have resulted
>>AP> in c being included in the local scope. Then rebinding and mutation
>>AP> would still be fundamentally different from each other but the specific
>>AP> confusion over why 'k[0] = ...' worked as expeced but 'k = ...' didn't,
>>AP> will disappear.
>
> That seems nonsense to me. If they had chosen that 'c.a = ...' would imply
> that c would become a local variable, what would the value of c have to be
> then, if there was no prior direct assignment to c?

I'm sorry to see you missed it, but since I had answered this already in
this thread I saw at the moment no need to repeat it: There would be no
value for c, the line would raise an UnboundLocalError.

I also don't understand why you take the trouble of attacking this
possibility. It's wasn't presented as a suggestion for changing python.
It was used as an illustration of why I think some explanation needs
to be worked out more. So even if this turns out to be the worst
possible that could ever happen to python, unless you think people
needing the original explanation will grasp the implication of this
possibility immediately, the point I wanted to illustrate seems to
stand.

-- 
Antoon Pardon