Pierre Barbier de Reuille wrote: > 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.
It's true that a different implementation of Python may use a different internal storage system for names, but as long as the semantics are the same as CPython, it really doesn't doesn't matter what the internal storage is. That is to say, as long as the other implementation of Python has __getattr__ and __dict__, you can use strings to represent names, regardless of how the interpreter stores them internally. > 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 ? It's just that, for the current interpreters and usage of "symbol-like" construct, the efficiency gained by the interpreter choosing how to represent symbols is probably *far* outweighed by the inefficiency and hassle of implementing and maintaining the symbol syntax in the existing interpreters. Besides, "have the programmer specify intent, and allow the interpreter to substitute a more efficient implementation on the off chance that interpreter can or wants to" doesn't have much cache in the Python community.(1) The interpreter could get more efficiency if it knew a list was fixed length, or contained only ints, or knew that a for loop was looping over consecutive integers, instead of a random list. But despite the possibility that there might exist, at some time in the future, a Python interpreter which *might* optimize such things, we haven't thrown in variable declarations or integer loop syntaxes yet. As I've mentioned before, the key to getting feature put into the language is compelling use cases. Find a (non-hypothetical) Python program or library which would be improved by addition of <insert your chosen feature here>, and where the existing alternatives are inadequate. Lacking that, any attempt to get a feature into the language is an uphill battle. > 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 ? One could flip it around and say that names *not* being strings are an implementation detail - after all, what is a name in your source code, besides just a string of ASCII characters? Having just names and strings simplifies things as well - you have only two items to convert between, as opposed to three items (names, symbols and strings). - (1) The future of Python seems to be towards the PyPy way, where the interpreter will analyze your code, and automagically determine the most efficient implementation for your particular use case. -- http://mail.python.org/mailman/listinfo/python-list
