Nested function scope problem

[Bruno Desthuilliers]

Antoon Pardon a écrit :
> 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.

No ?

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

Because the person I was replying to asked for the difference between 
C-like variables (which are mostly symbolic names for memory addresses 
storing bits) and Python's variable (which are mostly keys associated to 
a reference to an object).

> Lisp-like variables are different
> from C-like variables,

indeed.

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

Use the word that you want, I don't give a damn. I can't help if you're 
clueless enough to understand why I wanted to emphasis the difference.

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

Does it occurs to you that most languages are designed with specific 
requirements in mind ? (well, for those that are designed at least). And 
that a good part of these requirements are about or closely related to 
implementation issues ?

> If you have an issue with it, bring
> your arguments. The fact is that if you don't want to use the
> word variable,

I use it everyday.

> you can't rely on current implementation details,
> because implementation details can change without the language
> changing.

Yeah, great. Now you're done with theory, let's get pragmatic.

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

<aol>
Implementation detail.
</aol>

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

Oh, my...

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

I dont.

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

I don't care, and I really doubt anyone working on a C implementation 
cares much. C has been designed to be as simple as possible to 
implement, as close to the hardware as possible, and as fast as 
possible. It has been designed for system programming - actually to make 
Unix portable to other architectures. It's very obvious for anyone with 
a not too limited understanding that C design is very closely related to 
these goals.

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

fine.

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

The fact that it seems irrelevant to you seems totally irrelevant to me. 
  Good night.