Nested function scope problem

[Bruno Desthuilliers]

Antoon Pardon wrote:
> On 2006-07-27, Bruno Desthuilliers <onurb at xiludom.gro> wrote:
> 
(snip)
>>>>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

Guess where the term "binding" comes from.

> 
>>>to use
>>>the term.
>>
>>IYO.
> 
> 
> So? The statement that python doesn't has variables is just your opinion.

The statement that "Python doesn't has variables" is meant to emphasis
the very difference between C-like variables and Python bindings.

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

yes, your favourite argument ever.

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

You don't understand the difference between a list and a dict ?

FWIW, the module and the classes namespaces are really implemented with
dicts. Functions namespaces are not IIRC, but I can't find the link no more.

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

This is relevant when talking about the difference between C variables
and Python bindings.

> If someone would wish to extend
> python with a type system, 

In case you don't know, it already has one.

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

"could", yes. But I'm not talking about language grammar.

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

Someone in this thread used a 'post-it' metaphor that more or less
implied that the name was 'post-it'ed' on the object. Which is not the
case. Hence my precision on this.

And I still fail to get the whole point of your post.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"