Nested scopes, and augmented assignment

[Tim N. van der Leeuw]

Hi,

The following might be documented somewhere, but it hit me unexpectedly
and I couldn't exactly find this in the manual either.

Problem is, that I cannot use augmented assignment operators in a
nested scope, on variables from the outer scope:

PythonWin 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32.
Portions Copyright 1994-2004 Mark Hammond (mh******@skipp inet.com.au) -
see 'Help/About PythonWin' for further copyright information.

>>def foo():

.... def nestedfunc(bar) :
.... print bar, ';', localvar
.... localvar += 1
.... localvar=0
.... nestedfunc('bar ')
....

>>foo()

bar =Traceback (most recent call last):
File "<interacti ve input>", line 1, in ?
File "<interacti ve input>", line 6, in foo
File "<interacti ve input>", line 3, in nestedfunc
UnboundLocalErr or: local variable 'localvar' referenced before
assignment

>>>

This is entirely counter-intuitive to me, and searching the manual for
nested scoping rules and for augmented assignment rules, I still feel
that I couldn't have predicted this from the docs.

Is this an implementation artifact, bug, or should it really just
follow logically from the language definition?

Regards,

--Tim

[Bruno Desthuilliers]

Antoon Pardon wrote:

On 2006-07-06, Bruno Desthuilliers <on***@xiludom. growrote:

>>Antoon Pardon wrote:

>>>On 2006-07-05, Piet van Oostrum <pi**@cs.uu.nlw rote:
>>>It's not about "finding a name/identifier", it's about the difference
>>>betwee n (re)binding a name and mutating an object.

>APThe two don't contradict each other. Python has chosen that it won't
>APrebind variables that are out of the local scope. So if the lefthand
>APside of an assignment is a simple name it will only search in the
>APlocal scope for that name. But if the lefthand side is more complicated
>APif 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 "comfortabl e" 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 'o****@xiludom. gro'.split('@')])"

[Bruno Desthuilliers]

Piet van Oostrum wrote:
(snip)

There is no big difference I think. Only Python doesn't have syntax for the
former. Older versions of Python didn't even have nested scopes. maybe it
was a mistake to add them.

Certainly not. Nested scopes allow closures, which allow decorators and
lot of *very* useful things. Remove this from Python, and you'll see a
*lot* of experimented programmers switch to another language.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[Bruno Desthuilliers]

Antoon Pardon wrote:

On 2006-07-06, Piet van Oostrum <pi**@cs.uu.nlw rote:

>>>APAren't we now talking about implementation details? Sure the compilor
APcan set things up so that local names are bound to the local scope and
APso the same code can be used. But it seems somewhere was made the
APdecision that b was in the local scope without looking for that b in
APthe scopes higher up.

Yes, as I (and others) have already said several times: an assignment to a
variable inside a function body (but not an assignment to an attribute or
part of an object) without a global declaration makes that variable a local
variable. That is not an implementation detail; it is part of the language definition.

You seem to think I didn't understand this.

And he's right, cf below.

(snip)

Could you maybe clarify what problem we are discussing? All I wrote
was that with an assignment the search for the lefthand variable
depends on whether the lefthand side is a simple variable or
more complicated.

You're obviously clueless. Which would not be a problem if you did not
refuse to first aknowledge the fact then take appropriate actions.

Sure people may prefer to speak about (re)binding
vs mutating variables, but just because I didn't use the prefered terms,

If you refuse to understand that there are pretty good reasons to use
the appropriate semantic, that's your problem, but then no one can help
you.

starting to doubt my understanding of the language, seems a bit
premature IMO.

I do not 'doubt', I'm 111% confident.

I'm sure there are areas where my understanding of
the language is shaky, metaclasses being one of them, but understanding
how names are searched doesn't seem to be one of them.

It is, obviously.

And you're definitively a crank.

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

[Fredrik Lundh]

Bruno Desthuilliers wrote:

Certainly not. Nested scopes allow closures, which allow decorators and
lot of *very* useful things.

decorators can be trivially implemented as classes, of course. it's a
bit unfortunate that many people seem to think that decorators *have* to
be implemented as nested functions, rather than arbitrary callables.

</F>

[Antoon Pardon]

On 2006-07-07, Piet van Oostrum <pi**@cs.uu.nlw rote:

>>>>>Antoon Pardon <ap*****@forel. vub.ac.be(AP) wrote:

>>APCould you maybe clarify what problem we are discussing? All I wrote
APwas that with an assignment the search for the lefthand variable
APdepends on whether the lefthand side is a simple variable or
APmore complicated.

What do you mean with `the lefthand variable'? Especially when talking
about `complicated lefthand sides'?

The name on the left side of an assignment that refers to a variable,
as opposed to names that are attributes.

>>APSure people may prefer to speak about (re)binding
APvs mutating variables, but just because I didn't use the prefered terms,
APstarting to doubt my understanding of the language, seems a bit
APpremature IMO. I'm sure there are areas where my understanding of
APthe language is shaky, metaclasses being one of them, but understanding
APhow names are searched doesn't seem to be one of them.

You didn't understand it in your OP. Maybe your understanding has gained in
the meantime?

I don't rule out that I gained some understanding without noticing it.
Maybe my choice of words was poor then.

--
Antoon Pardon

[Antoon Pardon]

On 2006-07-07, Fredrik Lundh <fr*****@python ware.comwrote:

Antoon "I'm no nincompoop, but I play one on the internet" Pardon wrote:

>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
implementati on instead of just on language definition.

the behaviour *is* defined in the language definition, and has nothing
to do with a specific implementation.

As far as I can see I didn't write anything that contradicts this.
It is possible that at some point my choice of wording was bad
and that I gave the impression that i somehow wanted to contradict
this. If that happened my appologies.

have you even read the language
reference ? do you even know that it exists ?

You mean this, I suppose:

http://docs.python.org/ref/naming.html

--
Antoon Pardon

[Antoon Pardon]

On 2006-07-07, Fredrik Lundh <fr*****@python ware.comwrote:

Antoon Pardon wrote:

>>have any of your "my mental model of how Python works is more important
than how it actually works" ever had a point ?

Be free to correct me. But just suggesting that I'm wrong doesn't help
me in changing my mental model.

over the years, enough people have wasted enough time on trying to get
you to understand how Python works, in various aspects. if you really
were interested in learning, you would have learned something by now,
and you wouldn't keep repeating the same old misunderstandin gs over and
over again.

May be I misunderstand, maybe I sometimes have difficulties making my self
clear. If you already made up your mind which is it, that is fine by me.
I just don't see the point of just posting a response that just
boils down to: You are wrong. Even if you have given up on me, others
might be helped if you took the trouble of explainig what was wrong.

Well, that was just what I was thinking.

--
Antoon Pardon

[Bruno Desthuilliers]

Fredrik Lundh wrote:

Bruno Desthuilliers wrote:

>Certainly not. Nested scopes allow closures, which allow decorators and
lot of *very* useful things.

decorators can be trivially implemented as classes, of course. it's a
bit unfortunate that many people seem to think that decorators *have* to
be implemented as nested functions, rather than arbitrary callables.

Your of course right - and I should know better since AFAIK (IOW please
correct me if I'm wrong), closures and classes are somewhat
interchangeable .

OTHO, using closures can make things far more simple - just like having
functions being objects is not absolutely necessary for having HOF-like
features, but can make HOF much more simple. If you take back all these
kind of features from Python, you end up with something that's not
really better than Java - and then me run away screaming !-)

Thanks for the correction anyway.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[Terry Reedy]

"Antoon Pardon" <ap*****@forel. vub.ac.bewrote in message
news:sl******** ************@rc pc42.vub.ac.be. ..

others might be helped if you took the trouble of explaining
what was wrong.

Aside from F., I tried to explain what I think you said wrong. Did you
read it? Did it help any?

tjr

[Piet van Oostrum]

>>>>Antoon Pardon <ap*****@forel. vub.ac.be(AP) wrote:

>APOn 2006-07-07, Piet van Oostrum <pi**@cs.uu.nlw rote:

>>>>>>>Antoon Pardon <ap*****@forel. vub.ac.be(AP) wrote:

APCould you maybe clarify what problem we are discussing? All I wrote
APwas that with an assignment the search for the lefthand variable
APdepends on whether the lefthand side is a simple variable or
APmore complicated.

>>>
What do you mean with `the lefthand variable'? Especially when talking
about `complicated lefthand sides'?

>APThe name on the left side of an assignment that refers to a variable,
APas opposed to names that are attributes.

So let me get it clear:
In a.b = c, a is the lefthand variable, but b is not?

If that is what you mean then I interpret your statement

>AP`with an assignment the search for the lefthand variable
APdepends on whether the lefthand side is a simple variable or
APmore complicated'

as meaning that the search for `a' in `a.b = c' would be different than the
search for `a' in `a = b'. Well, it is not. But I can understand the
confusion. Namely, `a = b' introduces a binding for `a' in the local scope,
unless `a' was declared global. So the search will find `a' in the local
scope and it stops there. On the other hand `a.b = c' will not introduce a
binding for `a'. So the search for `a' may stop in the local space (if
there was another binding for `a' in the local scope) or it may need to
continue to outer scopes. The difference, however is not the
complicatedness of the lefthand side but whether the local scope contains a
binding for the variable.

--
Piet van Oostrum <pi**@cs.uu.n l>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C 4]
Private email: pi**@vanoostrum .org