Nested scopes, and augmented assignment

[Antoon Pardon]

On 2006-07-06, Bruno Desthuilliers <onurb at xiludom.gro> wrote:
> Antoon Pardon wrote:
>> On 2006-07-05, Piet van Oostrum <piet at cs.uu.nl> wrote:
>> 
>>>>>>It's not about "finding a name/identifier", it's about the difference
>>>>>>between (re)binding a name and mutating an object.
>>>
>>>>AP> The two don't contradict each other. Python has chosen that it won't
>>>>AP> rebind variables that are out of the local scope. So if the lefthand
>>>>AP> side of an assignment is a simple name it will only search in the
>>>>AP> local scope for that name. But if the lefthand side is more complicated
>>>>AP> if will also search the outerscopes for the name.
>
> Now it's pretty clear you *don't* understand.
>
> In the second case, ie:
>
> k = [0]
> def f(i):
>   k[0] += i
>
> 'k[0]' is *not* a name. The name is 'k'. If we rewrite this snippet
> without all the syntactic sugar, we get something like:
>
> k = [0]
> def f(i):
>   k.__setitem_(0, k.__getitem__(0) + i)
>
> Now where do you see any rebinding here ?

What point do you want to make? As far as I can see, I
didn't write anything that implied I expected k to
be rebound in code like

  k[0] += i

So why are you trying so hard to show me this?

>>
>>>No. It will always use the same search order.
>> 
>> 
>> So if I understand you correctly in code like:
>> 
>>   c.d = a
>>   b = a
>> 
>> All three names 
>
> which ones ?
>
>> are searched for in all scopes between the local en global
>> one. 
>
> In this example, we're at the top level, so the local scope is the
> global scope. I assert what you meant was:

I'm sorry I should have been more clear. I meant it to be 
a piece of function code.

> c = something
> a = something_else
>
> def somefunc():
>   c.d = a
>   b = a
>
> (NB : following observations will refer to this code)
>
>> That is what I understand with your statement that [python] always
>> uses the same search order.
>
> yes.
>
>> My impression was that python will search for c and a in the total current
>> namespace
>
> what is "the total current namespace" ?
>
>> but will not for b.
>
> b is bound in the local namespace, so there's no need to look for it in
> enclosing namespaces.

Now could you clarify please. First you agree with the statement that python
always uses the same search order, then you state here there is no need
to look for b because it is bound to local namespace. That seems to
imply that the search order for b is different.

AFAIR my original statement was that the search for b was different than
the search for a; meaning that the search for b was limited to the local
scope and this could be determined from just viewing a line like "b = a"
within a function. The search for a (or c in a line like: "c.d = a")
is not limited to the local scope. 

I may see some interpretation where you may say that the search order
for b is the same as for a and c but I still am not comfortable with
it.

>>>But a variable that is bound
>>>inside the function (with an asignment) and is not declared global, is in
>>>the local namespace.
>>  
>> Aren't we now talking about implementation details?
>
> Certainly not. Namespaces and names lookup rules are fundamental parts
> of the Python language.

I don't see the contradiction. That Namespaces and names lookup are
fundamentel parts of the Python language, doesn't mean that 
the right behaviour can't be implemented in multiple ways and
doesn't contradict that a specific explanation depend on a specific
implementation instead of just on language definition.

>> Sure the compilor
>> can set things up so that local names are bound to the local scope and
>> so the same code can be used. But it seems somewhere was made the
>> decision that b was in the local scope without looking for that b in
>> the scopes higher up.
>
> binding creates a name in the current namespace. b is bound in the local
> namespace, so b is local. period.

I wrote nothing that contradicts that.

-- 
Antoon Pardon