Nested scopes, and augmented assignment

[Piet van Oostrum]

Re: Nested scopes, and augmented assignment

>>>>Antoon Pardon <apardon@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'?

>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?
--
Piet van Oostrum <piet@cs.uu.n l>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C 4]
Private email: piet@vanoostrum .org

[Piet van Oostrum]

Re: Nested scopes, and augmented assignment

>>>>"Terry Reedy" <tjreedy@udel.e du(TR) wrote:

>TR"Antoon Pardon" <apardon@forel. vub.ac.bewrote in message
>TRnews:slrneap mfr.at1.apardon @rcpc42.vub.ac. be...

>>And if Nested variables are harmfull,

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

I used that phrase (with correct spelling). I had supposed that it would
be recognised as a variation of 'Global variables considered harmful',
(William Wulf and Mary Shaw, ACM SIGPLAN Notices, 1973, 8 (2) pp. 28--34).
I think nested variables have the same troubles as global variables, so
they should be used with care.
--
Piet van Oostrum <piet@cs.uu.n l>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C 4]
Private email: piet@vanoostrum .org

[Fredrik Lundh]

Re: Nested scopes, and augmented assignment

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.

</F>

[Fredrik Lundh]

Re: Nested scopes, and augmented assignment

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

the behaviour *is* defined in the language definition, and has nothing
to do with a specific implementation. have you even read the language
reference ? do you even know that it exists ?

</F>

[Fredrik Lundh]

Re: Nested scopes, and augmented assignment

Piet van Oostrum wrote:

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.

arbitrarily nested scopes, at least. the old local/global/builtin
approach (the LGB rule) is of course a kind of nesting; the new thing is
support for "enclosing scopes" in Python 2.1/2.2 (the LEGB rule). for
some background, see:

http://www.python.org/dev/peps/pep-0227/

the section "Rebinding names in enclosing scopes" discusses the 2.X-
specific thinking; this may be revised in 3.0 (see current python-dev
discussions).

</F>

[Bruno Desthuilliers]

Re: Nested scopes, and augmented assignment

Antoon Pardon wrote:

On 2006-07-06, Bruno Desthuilliers <onurb@xiludom. growrote:
>

>>Antoon Pardon wrote:
>>

>>>On 2006-07-05, Piet van Oostrum <piet@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 'onurb@xiludom. gro'.split('@')])"

[Bruno Desthuilliers]

Re: Nested scopes, and augmented assignment

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 'onurb@xiludom. gro'.split('@')])"

[Bruno Desthuilliers]

Re: Nested scopes, and augmented assignment

Antoon Pardon wrote:

On 2006-07-06, Piet van Oostrum <piet@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 'onurb@xiludom. gro'.split('@')])"

[Fredrik Lundh]

Re: Nested scopes, and augmented assignment

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]

Re: Nested scopes, and augmented assignment

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

>>>>>Antoon Pardon <apardon@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]

Re: Nested scopes, and augmented assignment

On 2006-07-07, Fredrik Lundh <fredrik@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]

Re: Nested scopes, and augmented assignment

On 2006-07-07, Fredrik Lundh <fredrik@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]

Re: Nested scopes, and augmented assignment

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 'onurb@xiludom. gro'.split('@')])"

[Terry Reedy]

Re: Nested scopes, and augmented assignment


"Antoon Pardon" <apardon@forel. vub.ac.bewrote in message
news:slrneask5e .ioc.apardon@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]

Re: Nested scopes, and augmented assignment

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

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

>>>>>>>Antoon Pardon <apardon@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 <piet@cs.uu.n l>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C 4]
Private email: piet@vanoostrum .org