Nested scopes, and augmented assignment

[Bruno Desthuilliers]

Antoon Pardon wrote:
> On 2006-07-05, Piet van Oostrum <piet at cs.uu.nl> wrote:
> 
>>>>>>>Antoon Pardon <apardon at forel.vub.ac.be> (AP) wrote:
>>
>>>AP> On 2006-07-05, Bruno Desthuilliers <onurb at xiludom.gro> wrote:
>>>
>>>>>Antoon Pardon wrote:
>>>>>(snip)
>>>>>
>>>>>>Well no matter what explanation you give to it, and I understand how it
>>>>>>works,
>>>>>
>>>>>I'm not sure of this.
>>
>>>AP> Should I care about that?
>>
>>Yes, because as long as you don't understand it, you are in for unpleasant
>>surprises. 
> 
> 
> Well if someone explains what is wrong about my understanding, I
> certainly care about that (although I confess to sometimes being
> impatient) but someone just stating he is not sure I understand?

>From what you wrote, I cannot decide if you really understand Python's
lookup rules and poorly express some disagreement on it, or if you just
don't understand Python lookup rules at all.

> 
>>>>>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 ?
>
>>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:

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.

> 
>>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.

> 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.

(snip)



-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"