Proposal for adding symbols within Python

Rocco Moretti roccomoretti at hotpop.com
Mon Nov 14 14:06:18 EST 2005


Pierre Barbier de Reuille wrote:
> Please, note that I am entirely open for every points on this proposal
> (which I do not dare yet to call PEP).

I still don't see why you can't just use strings. The only two issues I 
see you might have with them are a) two identical strings might not be 
identical by id(), b) they aren't local in scope.

The objection a) is minor. One, all of your examples use equality for 
testing already, and two, short strings are interned and identical in 
most cases anyway  (they only differ if you go to lengths to create 
them, or they aren't sufficiently "variable like") - at most you would 
have to standardize the rules.

The objection b) is a little harder to dismiss. But I'm not sure if 
you've completely thought what it means for a symbol to be "local to a 
module". What happens when you assign a variable containing a symbol to 
a variable in another module? For that matter, what does it mean to be 
"in a module". Which module is a class instance (and associated sybols) 
"in" if the class is defined in one module, instantiated in another, and 
then passed as a return value to a third? What about from ... imports? 
If you need a symbol "from another class" what's the mechanism of 
obtaining it? Can you import symbols? Since you advocate storing symbols 
internally as integers, I suppose you would have a program-global table 
to keep symbols from different modules from having the same internal 
representation. How do you pickle a symbol and have it go to a different 
Python program, which may have a massive symbol table of it's own?


It's been said before, and I'll say it again - the key to successful 
Python language changes is compelling use cases. Find an existing Python 
program or library (the stdlib is best) which would be markedly improved 
by your language change. Not only will Guido be more likely to be 
convinced, but what you're proposing will likely be clearer to everyone 
else, if it's grounded in practical use cases.



More information about the Python-list mailing list