Nested scopes, and augmented assignment

[Bruno Desthuilliers]

Antoon Pardon wrote:
> 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

Please re-read your own writing above.

> 
>   k[0] += i
> 
> So why are you trying so hard to show me this?
> 

I was just expecting to be of any help, but it seems you just *refuse*
to understand.

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

I still wait your explanation on this...

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

Yes : local namespace, then enclosing namespaces.

> then you state here there is no need
> to look for b because it is bound to local namespace. 

Yes. b being bound in the local namespace, it's found in the local
namespace, so lookup stops here. Pretty simple.

> That seems to
> imply that the search order for b is different.

cf above.


> AFAIR my original statement was that the search for b was different than
> the search for a;

And it's plain wrong, as anyone taking a few minutes reading the doc and
doing some tests would know.

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

Please repeat after me :
1/ binding in the local namespace makes the name local
2/ search order is local namespace first, then enclosing namespaces.

> I may see some interpretation where you may say that the search order
> for b is the same as for a and c

There's nothing to "interpret" here.

> but I still am not comfortable with
> it.

Too bad for you. But whether you are "comfortable" with reality is none
of my concern.

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

So go and get yourself some glasses.

> That Namespaces and names lookup are
> fundamentel parts of the Python language, doesn't mean that 
> the right behaviour

define "right behaviour" ?

> can't be implemented in multiple ways

I don't give a damn about how it's implemented.

> and
> doesn't contradict that a specific explanation depend on a specific
> implementation instead of just on language definition.
> 

This is totally meaningless.

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

I give up. You're a crank.


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