Martin v. Löwis wrote: > Kendall Clark wrote: > >>Thanks, Martin. That is, in fact, pretty much what I'd like to see in >>Py3K, modulo the issue about getattr. > > > The question is still: why? In Smalltalk, symbols are used to denote > names (methods/selector names and class names); this apparently isn't > your intention (and I do believe strings serve fine as names, no need > for a new datatype - except that it should support Unicode). > > So the only advantage I can see is the simplified typing: instead of > typing two quotation marks, you type a single colon. It might be > a saving on your keyboard that you don't have to press the shift key > (is colon available unshifted on US keyboards?); I have to press > the shift key either way (: is shift-.; " is shift-2).
Symbols make it clear you are talking about some more-constrained value (like an enumeration), or an in-process name (like a method name). Strings can just be data, which is generally used very differently. In addition to immutability, I think this is an important part of how symbols are used in Lisp and Ruby (they don't seem to actually be used as much in Smalltalk, more of an implementation detail). Also, when passed a string or symbol, you can get a better idea of what it was intended for. And, for example, having to cast the string to a symbol before using it with getattr() will make the security implications a little clearer. At the same time, I think it is more in line with Python's design to avoid talking about the names of things, and instead talk about the things themselves. After all, you don't do: make(:var, 10) You do: var = 10 In most cases this is how Python works now. Literal strings show up sometimes. I see them in descriptors (or complex tricks to avoid them). In hasattr() they are common, in getattr() occasionally to make use of the third getattr() argument -- either can be avoided with try:except AttributeError: if you choose. That's most of what I can think of now. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
