[Python-3000] symbols?
Kendall Clark
kendall at monkeyfist.com
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
More information about the Python-3000
mailing list