[Python-3000] symbols?

Tue Apr 11 22:37:10 CEST 2006

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