Nested scopes, and augmented assignment

[Bruno Desthuilliers]

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.

which ones ?



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

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.

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.

I wrote nothing that contradicts that.

I give up. You're a crank.

 

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

 

[Fredrik Lundh]

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>

 

[Bruno Desthuilliers]

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.

 

[Antoon Pardon]

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.

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]

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]

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

 

[Bruno Desthuilliers]

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.

 

[Terry Reedy]

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]

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

AP> The name on the left side of an assignment that refers to a variable,
AP> as 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
AP> depends on whether the lefthand side is a simple variable or
AP> more 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.

 

[Dennis Lee Bieber]

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

"a" is a reference to some object. "b" is a component INSIDE the
object. I phrase it this way because the concept is identical to
dictionary and list...

a[0] = c
a["myKey"] = c

"a" is the reference to some object (list or dictionary), [0] or
["myKey"] is a component INSIDE the object.

"= c" will make a binding of the inner component -- but does not
rebind the outer object.

Anytime you qualify a name with a ".<something>" or [<something>]
you are "opening" the object currently bound to the name, and modifying
the contents. Without the qualification, you are rebinding the name to a
new object; said object being whatever the RHS is currently bound to.

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Antoon Pardon]

I don't know if anyone said that they were, but Guido obviously does not
think so, or he would not have added them. So skip that.


A variable is a name. Name can be rebound (or maybe not) but they cannot
be mutated. Only objects (with mutation methods) can be mutated. In other
words, binding is a namespace action and mutation is an objectspace action.
In Python, at least, the difference is fundamental.

Or, in other other words, do not be fooled by the convenient but incorrect
abbreviated phrase 'mutate a nested variable'.

I'm not fooled by that phrase. I just think the mutate vs rebind
explanation is not complete.

If we have two statements "a = b" and "c.d = b" the fact that a is being
rebound while c is mutated doesn't explain why we allow c to be searched
out of the local scope.

By only stating that the first statement is a rebinding and the second
is a mutation and that this is a fundamental difference in python you
seem to suggest that this fundamental differenence implies this
difference in searching scopes. Python could have made the choice
that in an assignment the variable on the left side was always to
be searched in local space so that code like the following would
throw: UnboundLocalError: local variable 'c' referenced before assignment

c = SomeObject
def f():
c.a = 5

Now I'm not arguing python should have made this choice. But the
possibility shows IMO this has more to do with search policies
of names than with the distinction between a rebinding and a mutation.

AFAIK when nested scopes where introduced everyone agreed that scopes
had to have access to outer scopes. There were voices that supported
allowing a rebinding in an outer scope but no consensus on how to
do this was reached, so this possibility was dropped. So we can't
rebind an outer scope variable but we can mutate such a variable
because for mutation we only need access.

So does Guido. That is one explicit reason he gave for not choosing any of
the nunerous proposals for the syntax and semantics of nested scope write
access. In the face of anti-consensus among the developers and no
particular personal preference, he decided, "Better to wait than roll the
dice and make the wrong, hard to reverse, choice now". (Paraphrased quote)


Giving the actual history of, if anything, too many people thinking too
many different thoughts, this is almost funny.

Maybe I didn't made myself clear enough, but I never meant to imply
people hadn't thought thouroughly about this. If I gave you this
impression I appologize. What I was wondering about was that those
that had thought about it, would have reached a certain conclusion
that seemed suggested.

Recently however, Guido has rejected most proposals to focus attention on
just a few variations and possibly gain a consensus. So I think there is
at least half a chance that some sort of nested scope write access will
appear in 2.6 or 3.0.

Well I have browsed the discussion, which is why I react so lately to
this, and there is one thing I wonder about. As far as I can see no
suggestion removes the difference in the default search. The following
code will still work and won't need an outer statement. (or global,
nonlocal or whatever it will be)

c = SomeObject
def f():
c.a = 5

I don say they have to change this, but since it seemed decided this
was a python3k thing, i think the question deserved to be raised.

But I'm glad with this turn of events anyhow.

Just my 2 cent.

 

[Antoon Pardon]

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

Yes, b is an attribute of a

If that is what you mean then I interpret your statement

as meaning that the search for `a' in `a.b = c' would be different than the
search for `a' in `a = b'.

It is conceptually different. In the line 'a = b' you don't need to
search for the scope of a. You know it is the current scope, if you
want to know the scope of b on the other hand, you need to search
for statement where it is assigned to.

Sure you can set things up in the interpreter so that the same search
routine is used, but that is IMO an implementation detail.

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.

The complicatedness of the lefthand side, decided on whether the
variable was introduced in the local scope or not during startup
time. So that complicatedness decided whether the search was
to stop at the local level or not.

 

[Dennis Lee Bieber]

I'm not fooled by that phrase. I just think the mutate vs rebind
explanation is not complete.

If we have two statements "a = b" and "c.d = b" the fact that a is being
rebound while c is mutated doesn't explain why we allow c to be searched
out of the local scope.

The "search" is not different, per se... It is only after the object
is found that the difference becomes apparent -- a rebinding changes an
object's ID, and is not permitted for a non-local UNLESS a "global"
statement appears before any usage of the name.

"c.d =..." has absolutely no effect on the ID of object C; in that
aspect it is a read-only look-up of "c". IOWs, the same look-up as would
be used if "c" were on the RHS of the statement.

be searched in local space so that code like the following would
throw: UnboundLocalError: local variable 'c' referenced before assignment

c = SomeObject
def f():
c.a = 5

What would you say the behavior should be for:

c.a = c.b
vs
la = c.b

The look-up of "c" is the same on both sides of the statement; local
(not found) then global (found), THEN the operation is applied. On both
sides "c" is a read-only look-up (that is, no changes to the ID of "c"
-- no rebinding -- take place).

Are you suggesting we need to use "global c" in order to have "c.b"
on the RHS? By that logic, we would also need "global sys" to reference
"sys.argv" inside a function definition. Remember -- the modules loaded
by "import" are just more "SomeObject" samples...

import myCommon

def f():
myCommon.aVariable = someResult #permitted now

You would have us do...

import myCommon

def f():
global myCommon
myCommon.aVariable = someResult

.... just because "myCommon" is on the LHS within a function?

Or, conversely, you don't want the following to flag an error, when
it might be a typo that loses the ".component"?

import myCommon

def f():
myCommon = someResult #no qualifier
# you've just lost access to all the internals of the module
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Piet van Oostrum]

AP> It is conceptually different. In the line 'a = b' you don't need to
AP> search for the scope of a. You know it is the current scope, if you

Except when it has been declared global.

AP> want to know the scope of b on the other hand, you need to search
AP> for statement where it is assigned to.

AP> Sure you can set things up in the interpreter so that the same search
AP> routine is used, but that is IMO an implementation detail.

AP> The complicatedness of the lefthand side, decided on whether the
AP> variable was introduced in the local scope or not during startup
AP> time. So that complicatedness decided whether the search was
AP> to stop at the local level or not.

No, it doesn't. There could be another binding in the same scope. The
complicatedness of this particular assignment doesn't decide anything about
how to search for 'a', but rather the presence or absence of a binding
anywhere in the scope.

 

[Antoon Pardon]

Except when it has been declared global.

Yes, I ignored that possibilitym because as far as I understood we
were discussing variables in intermediate scopes.

No, it doesn't. There could be another binding in the same scope.

Indeed there could be. But I hoped you would understand I was just
keeping things simple, with a simple example.

The
complicatedness of this particular assignment doesn't decide anything about
how to search for 'a', but rather the presence or absence of a binding
anywhere in the scope.

I'll word it differently. If the compiler encounters a line like 'a = b'
then you know from that line alone that the search space for a will be
limited to the local scope. If you encounter a line like 'a.c = b' then
you have no such knowledge. A line like 'a = b' will cause the compilor
that at call time variable a will be added to the local scope, a line like
'a.c = b' will not have that effect. So a line like 'a = b' has an
influence on what the search space is for variable a, while a line
like 'a.c = b' doesn't. So the complicatedness on the leftside decides
whether or not the compilor will take certain actions with regards to
the search space of the variable on the left side.

And yes I'm again ignoring global.

 

[Antoon Pardon]

The "search" is not different, per se... It is only after the object
is found that the difference becomes apparent -- a rebinding changes an
object's ID, and is not permitted for a non-local UNLESS a "global"
statement appears before any usage of the name.

"c.d =..." has absolutely no effect on the ID of object C; in that
aspect it is a read-only look-up of "c". IOWs, the same look-up as would
be used if "c" were on the RHS of the statement.

What would you say the behavior should be for:

c.a = c.b
vs
la = c.b

The look-up of "c" is the same on both sides of the statement; local
(not found) then global (found), THEN the operation is applied. On both
sides "c" is a read-only look-up (that is, no changes to the ID of "c"
-- no rebinding -- take place).

Are you suggesting we need to use "global c" in order to have "c.b"
on the RHS? By that logic, we would also need "global sys" to reference
"sys.argv" inside a function definition. Remember -- the modules loaded
by "import" are just more "SomeObject" samples...

I think you are misunderstanding what I was getting at. This example was
not meant to illustrate how I think python should behave. I thought I
had made that clear.

When someone gets confused over the difference between rebinding or mutating
a variable on an intermediate scope, the explanation he mostly seems to get
boils down to: one is rebinding, the other is mutation, this is a fundametal
difference in python.

My impression is that they seem to say that the fundamental difference
between mutation and rebinding implies the specific behaviour python
has now. IMO this explanation is incomplete. The python developers
could have chosen that a line like 'c.a = ...' would have resulted
in c being included in the local scope. Then rebinding and mutation
would still be fundamentally different from each other but the specific
confusion over why 'k[0] = ...' worked as expeced but 'k = ...' didn't,
will disappear.

So I only used this example as an illustration why I think the usual
explanation is not completed. This example is not to be taken as an
illustration of how I think python should behave.

 

[Piet van Oostrum]

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? Would it become a new
binding like in 'c = ...'? From what class should it become an instance? Or
would it become a copy of the value that 'c' has in an outer scope? I don't
know any programming language where an assignment to c.a does create a new
c, rather than modifying the existing value of c. That would have been a
very strange language design. Similarly for 'k[0] = ...'. What would happen
with the other elements of k?

There are no situations in Python where an assignment to c.a or c[0]
suddenly lets spring c into existence. You always need an already existing
binding for c for this to be valid. And it always uses that binding, and
doesn't move or copy it to a different block.

Some of the confusing originates from the fact that assignment in Python is
subtly different from assignment in other programming languages. In most
languages variables denote memory locations or collections of memory
locations. An assignment then means changing the contents of those memory
locations. In python variables are bound to values, and assignment means
(re)binding the name to a possibly different value. With an example: most
other languages have boxes with the name of the variable on them. An
assignment changes the contents of the box. In Python you have values
(objects) and an assignment means sticking a label with the name of the
variable on the object. Often the difference is unnoticable, but there are
subtle cases where this really makes a difference.

When the lefthandside of an assignment is an object attribute, subscription
or slice then the assignment is syntactic sugar for a mutation operation
implemented by the object, which usually changes the value of the object
but could do something completely different.

(Finally, the lefthandside can also be a [nested] tuple or list, in which
case it is a collection of parallel assignments. And oh yes, there are also
other binding operations e.g. a function or class definition.)

 

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

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.

 

[Piet van Oostrum]

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

OK. That could have been chosen. But that would mean that instead of c.a =
b, where c is bound in a non-local scope, you have to write something like:

cc = c
cc.a = b

I don't find that useful.