Ben Finney wrote: ... > I've yet to see a convincing argument against simply assigning values > to names, then using those names.
I don't like any syntax I've seen so far, but I can understand the problem. If you have a name, you can redefine a name, therefore the value a name refers to is mutable. As a result if you have 2 symbols represented by names and values, you may have two symbols with different names but the same value. Hence the two "symbols" are no longer unique) Conversely consider "NAME" to be a symbol. I can't modify "NAME". It always means the same as "NAME" and "NAME", but is never the same as "FRED". What's tricky is I can't have namespaceOne."NAME" [1] and namespaceTwo."NAME" as different "NAME"s even though logically there's no reason I couldn't treat "NAME" differently inside each. [1] Supposing for a moment that I could have a string as a name in a namespace. (Rather than a string used as a key in that namespace) However it might be useful to note that these two values (or symbols) are actually different, even if you remove their namespaces. To me, the use of a symbol implies a desire for a constant, and then to only use that constant rather than the value. In certain situations it's the fact that constant A is not the same as constant B that's important (eg modelling state machines). Often you can use strings for that sort of thing, but unfortunately even python's strings can't be used as symbols that are always the same thing in all ways. For example, we can force the id of identical strings to be different: >>> s = "h"*10000 >>> x = "h"*10000 >>> id(s), id(x) (135049832, 135059864) As a result I can see that *IF* you really want this kind of symbol, rather than the various other kinds people have discussed in the thread, that some special syntax (like u'hello' for unicode 'hello') could be useful. However, I'd be more interested in some real world usecases where this would be beneficial, and then seeing what sort of syntax would be nice/useful (Especially since I can think of some uses where it would be nice). On the original syntax proposal, I'm firmly in the -1 camp - to me having done lots of perl in the past $foo looks very firmly like a mutable, rather than an immutable. The reason I'm more interested in seeing usecases, is because I'd rather see where the existing approaches people use/define symbols has caused the OP problems to the extent he feels the language needs to change to fix these real world problems. Michael. -- http://mail.python.org/mailman/listinfo/python-list