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

I don't see how that is relevant.

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

And why should that be relevant? Lisp-like variables are different
from C-like variables, but that doesn't stop us from using the
word "variable". So why should the difference between C-like
variables and Python bindings be important enough to no longer
use that word.

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

What is your point? That it is my favourite argument ever doesn't
make it wrong or invalid. If you have an issue with it, bring
your arguments. The fact is that if you don't want to use the
word variable, you can't rely on current implementation details,
because implementation details can change without the language
changing.

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

If you use __slots__, the class namespaces is implemented as a list.
Unless when you add __dict__ to the slots, in that case you have
some kind of hybrid system.

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

It is irrelevant because the word "variable" is used in a lot of
different languages. A lot of them with behaviour closer to python
than to C. The difference between C variables and Python bindings
is only relevant if it can give you an argument for why we shouldn't
use "variable" when discussing python.

>> If someone would wish to extend
>> python with a type system, 
>
> In case you don't know, it already has one.

I'll be more clearer: If someone wants to extend python with
a kind of static typing, where you could limit names binding only
to objects of a certain number of classes, it wouldn't essentially
change what could be done with names in python, but the names would now
hold type information too. So whether a name carries type information
or not, has little relevance to whether the term "variable" is appropiate
or not.

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

Neither am I, I am talking about language semantics.
If a C-implementation could use directories, that means
that directories can be used to capture the C-semantics. 
So whether the implementation uses direct translation
from name to memory to bits or uses directories, it
doesn't change one bit what one can do with a variable
in the language.

Besides, you don't seem to have a problem talking about
Lisp-variables, and Lisp-variables don't have such
a direct translation from symbolic name to memory
address either. So this specific detail of most C-implementations
seems mostly irrelevant to me.

-- 
Antoon Pardon