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