[Python-3000] symbols?

[Kendall Clark]

On Apr 14, 2006, at 4:43 AM, Guido van Rossum wrote:

>> Kendall Clark wrote:
>>> I don't know if the Ruby syntax for symbols, :foo, will work in
>>> Python (though I think visually it's a good thing), but it would be
>>> really nice to have symbols with *some* syntax in Python 3000.
>>>
>>> Again, this design request is based on aesthetics and fun: having
>>> symbols would make Python more fun.
>
> I don't see how this particular feature adds more fun; I'd rather see
> it argued on the basis of use cases.

Fair enough. My primary use case is using Python as a host for a  
Domain Specific Language. This may not be a core Python use case,  
though I don't know if that's true. It is something that happens a  
lot in Ruby (Rails has been described as a DSL for Web programming),  
Haskell, and Common Lisp.

I think having a symbol type makes writing DSLs in Python easier  
(hence, my claim about "more fun"), since you can use symbols to  
reflect terms from the domain of the DSL in Python in a relatively  
easy way. Easier than creating a module full of constants or  
variables. Perhaps not really easier than using strings, but it  
expresses one's intent more clearly, IMO -- in a way I find analogous  
to using tuples instead of lists in some cases.

> The aesthetics of the earlier proposal to use :foo to indicate symbols
> are poor; using random punctuation is unpythonic (as is the use of ?
> or ! in identifiers BTW) but more importantly there are a few
> syntactic positions where it would be ambiguous, e.g. foo[:bar]
> already means foo[0:(bar)].

Good points. (Though I don't concede that "?" and "!" in method or  
function identifiers is random. But that's beside the point.)

I worried that :foo might make the grammar ambiguous, and I should  
have thought about that more.

I'm more interested in having a symbol type than any particular  
concrete syntax, FWIW. So I'm happy to consider the :foo variant dead  
in the water.

> I'd also like to point out (again?) that the "const-ness" of ALLCAPS
> is a red herring; in practice, we treat almost all imported names as
> constants, and in fact class and function names are generally
> considered constant. (I've also seen plenty of code that used ALLCAPS
> to indicate "configuration parameter" rather than "constant" and which
> freely assigned to ALLCAPS variables in configuration code.)

Agreed. I don't read ALLCAPS in Python as meaning constant. I almost  
always use it as configuration parameter, for cases where a separate  
configuration mechanism isn't warranged.

> Somewhat unrelated: there's one advantage to enums (which have been
> suggested as an alternative to symbols) which symbols don't share: if
> you have a typo in an enum name, you presumably get an early, hard
> NameError or AttributeError (and pychecker could easily check this);

Yes, absolutely. That's entirely true. I assume that enums will be  
more heavyweight to create (that is, more keystrokes than simply  
writing the symbol straight away), which is perhaps an advantage for  
symbols. I'd like to see both added to Py3k.

> but if you misspell a symbol, you just pass a different symbol, which
> is likely to trigger a later error or no error at all (depending on
> how the symbol is used). Of course, enums really serve a different use
> case; they wouldn't help at all for the property-defining use case
> Nick described here.

Agreed; I think they are distinct and should be considered orthogonally.

Cheers,
Kendall