On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Antoon Pardon a écrit : >> 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. > > No ?
Do you actually have a point? I doubt it because I would otherwise have expected that you would actually have presented it by now. >>>> >>>>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). That is no reason to say that python has no variables. If someone would explain the difference between objects in some other language and objects in python I wouldn't accept the statement: "python has no objects" either. >> 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. Stating that one language has no variables, looks a poor choice of words to me for saying that variables in C and python don't behave entirely the same. >>>>>>>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 ? Yes and it is irrelevant. That a number of requirements don't leave the implementor much choice, doesn't contradict that specific details are implementation details, and that you can't argue whether or not python has variables based on details of a specific implementation. >> 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. But you did write that python didn't have variables. >> 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. That doesn't change a thing. What one can do with the language is defined by the language reference. Not by a specific implementation. >>>>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. So what? This is not about *you*. So what you want or not is totally irrelevant. You just made a smart ass remark and cut away the point being made. That the second time I see you responding like that. Don't you have real arguments? >>>>>>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. Again irrelevant. That these are the goals of those who design(ed) C, doesn't mean other implementations are impossible. C interpreters do exist. And such an interpreter can use directories for managing his namespaces. >> 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. But that you don't present much arguments for your case, seems very relevant to me. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
