Nested function scope problem

[Antoon Pardon]

On 2006-07-27, Bruno Desthuilliers <onurb at xiludom.gro> wrote:
> danielx wrote:
>> Bruno Desthuilliers wrote:
>> 
> (snip)
>>>
>>>>Surprising for me are actually two things: 1- the fact itself, and 2- that
>>>>term "binding", and that whatever it means > (I'll have to read more on that,
>>>>now that I know the term)
>>>
>>>a "binding" is the association of a name and a reference to an object in
>>>a given namespace. It's different from the common notion of "variable",
>>>which is usually a symbolic name for a memory address storing a value
>>>(like a pointer to an object's address).
>> 
>> 
>> Wait, I'm not sure I see the difference. Isn't "reference" ~ "C
>> pointer". 
>
> For a very large definition of '~' !-)
>
>> Are you saying Python variables don't hold references to
>> "actual" Python objects? 
>
> Exactly.
>
>> That idea has been working well for me so far.
>
> It can only take you so far. Now it's time you know the truth: there are
> *no* 'variables' in Python (hence the term 'binding').

That depends on what you want to mean with the term. IMO 'variables'
in python behave sufficiently similar as in other languages to use
the term.

> What you really have is (somewhat simplified, of course) a dict with
> names as keys and objects references (think of 'smart' pointers) as
> values.

That is just an implementation issue. Nothing prevents variables to
be associated with an index in a list.

> So the name doesn't 'hold' anything - it's really nothing more
> than a name.

In a language like C the name doesn't hold anything either. 
The name is just a way for refering to a memory space which
will hold something.

> And the object doesn't know nothing about which names it's
> bound to.

In a language like C, the value '3' doesn't know which variables
will hold it either.

-- 
Antoon Pardon