Proposal for adding symbols within Python

[Rocco Moretti]

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.