Proposal for adding symbols within Python

Pierre Barbier de Reuille pierre.barbier at cirad.fr
Sat Nov 12 12:59:39 EST 2005


Please, note that I am entirely open for every points on this proposal
(which I do not dare yet to call PEP).

Abstract
========

This proposal suggests to add symbols into Python.

Symbols are objects whose representation within the code is more
important than their actual value. Two symbols needs only to be
equally-comparable. Also, symbols need to be hashable to use as keys of
dictionary (symbols are immutable objects).

Motivations
===========

Currently, there is no obvious way to define constants or states or
whatever would be best represented by symbols. 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).

Many languages propose symbols or obvious ways to define symbol-like
values. For examples in common languages:

In C/C++ : Symbols are emulated using Enums.
In Haskell/OCaml : Symbols are defined by union types with empty
constructors. Symbols are local to modules.
In Prolog : Symbols are called atoms ... they are local to modules (at
least in swi-prolog)
In Ruby : Symbols are introduced be the ":" notation. ":open" is a
symbol. Symbols are global.
In LISP : Symbols are introduced by "'". "'open" is a symbol. Symbols
are local to modules.

Proposal
========

First, I think it would be best to have a syntax to represent symbols.
Adding some special char before the name is probably a good way to
achieve that : $open, $close, ... are $ymbols.

On the range of symbols, I think they should be local to name space
(this point should be discussed as I see advantages and drawbacks for
both local and global symbols). For example, for the state of the file
object I would write :

>>> file.$open, file.$close, file.$error

Then, given some other objects (say some other device which also may be
opened) :

>>> assert f.state != dev.state

would always hold if both objects use locally-defined symbols. The only
way for these states to be equal would be, for example, for the device
object to explicitly assign the file symbols :

>>> dev.state = file.$open

By default, symbols should be local to the current module. Then, being
in the module "device_manager", this would hold:

>>> assert $opened == device_manager.$opened

There should be a way to go from strings to symbols and the other way
around. For that purpose, I propose:

>>> assert symbol("opened") == $opened
>>> assert str($opened) == "opened"

Implementation
==============

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

The End
=======

Thanks to those who read entirely this proposal and I hope this proposal
will gather enough interests to become a PEP and someday be implemented,
maybe (probably?) in a completely different way ;)

Pierre



More information about the Python-list mailing list