P
Pierre Barbier de Reuille
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. "pen" 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 :
Then, given some other objects (say some other device which also may be
opened) :
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 :
By default, symbols should be local to the current module. Then, being
in the module "device_manager", this would hold:
There should be a way to go from strings to symbols and the other way
around. For that purpose, I propose:
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
(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. "pen" 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 :
Then, given some other objects (say some other device which also may be
opened) :
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 :
By default, symbols should be local to the current module. Then, being
in the module "device_manager", this would hold:
There should be a way to go from strings to symbols and the other way
around. For that purpose, I propose:
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