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