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 ? >>> >>>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. -- http://mail.python.org/mailman/listinfo/python-list
