Nested function scope problem

[Antoon Pardon]

On 2006-07-27, Bruno Desthuilliers <onurb at xiludom.gro> wrote:
> Antoon Pardon wrote:
>> 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
>
> Which ones ? C ? or Lisp ? Or Haskell ?

Whatever, if both C and Lisp can both talk about variables, I don't
see why python can't

>> to use
>> the term.
>
> IYO.

So? The statement that python doesn't has variables is just your opinion.

>>>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.
>
> Do you understand what "somewhat simplified" means ?

Not the difference between a list and a dictionary.

>>>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. 
>
> Yes : it holds type and storage class informations too.

If you want so. But that is totally irrelevant for considering
something as a variable or not. If someone would wish to extend
python with a type system, so that a variable could be associated
with type information, it would not essentially change what
one could do with an identiefier in python.

Like wise one could make a C-like language without type and
storage class information associated with identifiers. Variables
would essentially still behave the same.

>> The name is just a way for refering to a memory space which
>> will hold something.
>
> The name is a symbolic name for a memory address in which bits will be
> stored (and the type information is used to know how to interpret the
> bits at this address - I leave storage class problems aside). There's a
> direct translation from symbolic name to memory address to bits.

That doesn't need to be. A C-implementation could use directories.
Most implementations don't but that is just because it would slow
performance, but perfectly legal C-behaviour would be possible.

Besides what you say isn't true in general. There is no direct
translation from a local name to memory address. The same name
can refer to a different memory address on different invocations
of the function.

> Which is not the case in Python...

An implementation detail.

>>>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.
>
> Indeed. Now could you tell us what was your point, exactly ?

Just showing that the object not knowing which identifiers
it is bound to is irrelevant.

-- 
Antoon Pardon