[Python-3000] symbols?

Michael Chermside mcherm at mcherm.com
Wed Apr 12 14:15:14 CEST 2006


Kendall Clark writes:
> 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

When I see a variable name in all-caps, I don't assign to it. I don't
even need a tool like PyChecker to remind me that this is a constant
because I've been familiar with the "all-caps == constant" convention
from shortly after I got a computer with lower-case letters on it.
The other programmers I work with seem to behave the same way. I must
be unusually lucky in this regard, because I meet lots of people who
are very concerned about the fact that it *is* possible to change
these values. I can only surmise that they work with people who make
a habit of modifying all-caps variables randomly just for fun.

I've found it even more curious that no one ever seems to be worried
about the ability to write infinite loops ("while True: pass") in
pretty much any piece of code. Of course, I suppose it might have
something to do with the fact that the haulting problem makes it
theoretically impossible to prevent all infinite loops. But it's
funny how no one considers this capability to be a dangerous flaw in
the language... perhaps because it just doesn't happen often. But I
will say that I've encountered more bugs due to infinite loops than
bugs due to modification of "constants".

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

Now that argument I *understand*, even if I don't find myself convinced
by it. I used to think that way too, but I guess "practicality" has
sunk in over the years.

And there's also:
> 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.

I don't write enough Python-based DSLs in Python to hold an informed
opinion on this one.

-- Michael Chermside



More information about the Python-3000 mailing list