On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: >> On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
