[Python-3000] symbols?

[Kendall Clark]

On Apr 10, 2006, at 8:11 PM, Greg Ewing wrote:

> Kendall Clark wrote:
>
>> One thing I'd really like to see in Python 3000 is support for first-
>> class symbols, with literal syntax.
>
> Actually I think enumerations would be more useful than
> symbols.

I don't see why we couldn't have both or neither. No *real*  
connection between them, not really.

> There's no essential difference between a symbol
> and an interned string.

Well, some differences. In Ruby, for example, symbols are global in  
scope and strings aren't. (Well, also, in Ruby, symbols are  
immutable, but Python strings are, so that's not really relevant.)  
The other difference (which you may not think essential) is that  
strings have lots of methods that are *never* relevant to the uses  
one would put a symbol. That may or may not bother anyone, but it is  
a difference. Symbols wouldn't have methods like strings have.

And there is a *bit* more work in using strings bound to variables  
(or using instances of classes, like yr SymGen example in the other  
thread) as opposed to using symbols with a literal syntax. I think in  
many cases symbols win on points for convenience and also express  
intent more clearly (similarly to the way tuples express some intent  
vis-a-vis using lists instead).

I agree, however, that none of these alone are decisive differences  
or advantages. I think the sum of the differences warrants having  
symbols in Python, but YMMV.

Though I don't see why Py3k couldn't have symbols and enumerations.

> The only real disadvantage to
> using strings as symbols is that you don't get an
> immediate NameError if you misspell one.

Well, as I said above, there is a difference in scope between a  
symbol (as I would like to see it added to Py) and a string. And I  
think there's more work to using strings as symbols.

> A symbol type
> wouldn't solve that problem; enumerations would.

Nope, :foo and :Foo are different symbols, no doubt about that.

Cheers,
Kendall