Nested function scope problem

[Antoon Pardon]

On 2006-07-30, Gerhard Fiedler <gelists at gmail.com> wrote:
> On 2006-07-30 09:54:14, Antoon Pardon wrote:
>
>> Aren't you looking too much at implementation details now?
>
> Possibly, but at this point I'm still trying to understand how Python does
> these things, and what the useful abstraction level is for me. I also still
> have very little experience how I'll put the things we've been discussing
> here into (Python) practice. While not new to programming, I'm new to
> Python.
>
>> AFAIU, one can also build a C++ class hierarchy that with some small
>> limitations in used operators, would have semantics very similar to
>> Python. Would you argue that those using such a C++ class hierarchy would
>> no longer be using variables in C++?
>
> Probably not. But for me it's mostly about useful terminology, not
> necessarily "correct" terminology. In order to talk about correct
> terminology, we'd have to use a common definition of "variable". This is a
> term so widely used that I'm not sure there is a useful single definition
> of it; do you know one?

A name in a scope to which is attached some value/object. Now whether
this attachment is in the form of storage or binding is IMO not
that important.

> In any case, the following doesn't seem to be implementation detail (and
> rather a part of the language), but it's not really understandable with a
> C++ concept of "variable":
>
>>>> a=3
>>>> id(a)
> 3368152
>>>> b=a
>>>> id(b)
> 3368152
>>>> b=4
>>>> id(b)
> 3368140
>
> You don't expect the "identity" of the variable b to change with a simple
> assignment from a C/C++ point of view.

That depends on what you call the identity. If I had to translate this
into C++ it would be something like:

  int *a, *b;

  a = MakeInt(3);
  b = a;
  b = MakeInt(4);

AFAIU, you can wrap these int pointers into some kind of class, so that
they behave as you would expect integers to behave. The id(a) would just
return a, the address of where the integer is stored.

Now whether this is helpfull or not for you in understanding the python
behaviour, I don't know. So if you think this is mixing to many things
I'll drop it.

> You also don't expect the "identity"
> of a and b to be the same after assigning one to the other. You can create
> C++ classes that behave like that (you can implement Python in C++ :),

I'm sorry but IMO you there is no connection between those two.
C doesn't have classes, yet you can still implement Python in C.

> but
> that doesn't mean that you expect C++ language constructs to behave like
> that.

If you have implemented it with that purpose, you do.

-- 
Antoon Pardon