Proposal for adding symbols within Python

Ben Finney bignose+hates-spam at
Sat Nov 12 22:47:02 CET 2005

Pierre Barbier de Reuille <pierre.barbier at> wrote:
> This proposal suggests to add symbols into Python.

I still don't think "symbol" is particularly descriptive as a name;
there are too many other things already in the language that might
also be called a "symbol".

> Symbols are objects whose representation within the code is more
> important than their actual value.

An interesting 

> Two symbols needs only to be equally-comparable.

I believe it would be more useful to have enumerated types in Python,
which would also allow values from the same type to be cmp() compared.

> Currently, there is no obvious way to define constants or states or
> whatever would be best represented by symbols.

"constants" isn't a good equivalent here, since constants in most
other languages are all about the name-to-value mapping, which you
said was unimportant for this concept.

> Discussions on comp.lang.python shows at least half a dozen way to
> replace symbols.


> Some use cases for symbols are : state of an object (i.e. for a file
> opened/closed/error) and unique objects (i.e. attributes names could
> be represented as symbols).

That pretty much covers the common use cases. Nicely done.

> First, I think it would be best to have a syntax to represent
> symbols.

I disagree. Namespaces would be fine, and would also make clear which
values were related to each other; e.g. for your "state of an object"
use case, it's useful to have all the states in one namespace,
separate from unrelated states of other classes of objects.

> Adding some special char before the name is probably a good way to
> achieve that : $open, $close, ... are $ymbols.


    FileState = SomeTypeDefiningStates( 'open', 'closed' )

    thefile.state =
    if thefile.state == FileState.closed:
        print "File is closed"

So all that's needed here is the type SomeTypeDefiningStates, not a
new syntax.

> One possible way to implement symbols is simply with integers
> resolved as much as possible at compile time.

I believe all your requirements and motivations could be met with an
Enum type in the language. Here's an implementation using a sequence
of integers for the underlying values:

    "First Class Enums in Python"

An enumerated type would also allow values from that type to be
compared with cmp() if their sequence was considered important. e.g.
for object state, the "normal" sequence of states could be represented
in the enumeration, and individual states compared to see if they are
"later" that each other. If sequence was not considered important, of
course, this feature would not get in the way.

 \      "I put instant coffee in a microwave oven and almost went back |
  `\                                       in time."  -- Steven Wright |
_o__)                                                                  |
Ben Finney

More information about the Python-list mailing list