[Python-3000] symbols?

[Kendall Clark]

On Apr 11, 2006, at 4:09 PM, Ian Bicking wrote:

> 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 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.

Yeah, my primary motivation is summed up nicely here; in some cases a  
symbol expresses intent better (IMO) than a string.

>   And, for example, having to cast the string to a symbol before  
> using it with getattr() will make the security implications a  
> little clearer.

Yep.

> 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.

They get used as terms in Domain Specific Languages in Python. Or,  
more commonly, one writes some king of generic symbol-like class that  
just wraps the string. But then everyone has to repeatedly reinvent  
that wheel. I guess it depends on how often Python is used as a host  
language for DSLs. But I tend to do a lot of that kind of programming  
(or, rather, a high percentage of the programming I do is of that  
type). So embedding a rule engine (with syntax for rules & facts) in  
Python is harder w/out symbols than it would be with them.

>   I see them in descriptors (or complex tricks to avoid them).

Yeah, Pylons just got this syntax for web-dispatching:

    @pylons.rest.restrict("GET", "HEAD")
    def get_instance(self, id): pass

Okay, so HTTP methods are so well know that the intent there is very  
clear. But it's less so when yr talking about some less known DSL,  
perhaps one written for a specific application.

The other choice, of course, is for the library or API to define some  
variables bound to strings and then use them like constants, except  
that they can get redefined:

    @pylons.rest.restrict(GET, HEAD)
    ...

A symbol has the advantage that it can't be assigned to, so can't  
change like a variable, but expresses more clearly than a string the  
intent to refer to a name or term, not string data:

    @pylon.rest.restrct(:GET, :HEAD)

>   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.

I think Ian put his finger on a good point, as usual: in Python we  
refer to things, not to their names, more often. But if you want to  
embed little languages in Python, you refer to the names of things  
from some other domain pretty often. Yeah, this is more of a Lisp or  
Ruby or Haskell application, but I prefer Python for lots of reason  
and want to use it for writing DSLs.

In that kind of app, strings get used to represent terms and names  
pretty often, and it just doesn't *feel* right. :>

Cheers,
Kendall