Rocco Moretti a écrit : [...] > > > I did, but I still don't see why it is an argument against using > strings. The point you may not appreciate is that (C)Python already uses > strings to represent names, as an important part of its introspective > abilities. >
Well, I'm well aware of that, but I'm also well aware that's (as you said yourself) specific to C-Python, so can just *cannot* rely on strings being used as symbols in the language. What I would like to see in Python is "names" (or "symbols", as you prefer) defined within the language so that you'll get something similar in whatever Python implementation. Then, in CPython, names may well be just strings are they already are implemented to be efficient as such, but other implementation may just choose something completly different. The point is, why don't provide the programmer to express just what he needs (that is, some symbolic value like "opened", "blocked", ...) and let the interpreter use whatever he think is more efficient for him ? That's the whole points for "names" ... being able to handle symbolic values within the language, that's what made LISP so successful. That's what makes dynamic languages possible ! But why say a name is a *string* when it is just an implementation detail ??? Isn't Python mainly about allowing the programmer to concentrate on important stuff ? Pierre -- http://mail.python.org/mailman/listinfo/python-list
