Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Ben Finney a écrit :
> Pierre Barbier de Reuille <pierre.barbier at cirad.fr> 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".

Well, that's the name in many languages. Then, probably all the things
already in the language that might be called "symbol" may be implemented
using the symbols in this proposal ... or maybe I don't see what you
mean here ?

> 
[...]
>>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.
> 
> 
> Counterproposal:
> 
>     FileState = SomeTypeDefiningStates( 'open', 'closed' )
> 
>     thefile.state = FileState.open
>     if thefile.state == FileState.closed:
>         print "File is closed"
> 
> So all that's needed here is the type SomeTypeDefiningStates, not a
> new syntax.

The problem, IMHO, is that way you need to declare "symbols"
beforehands, that's what I was trying to avoid by requiring 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"
>     <URL:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413486>
> 
> 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.
> 

Well, I don't think enumarated objects ARE symbols. I can see two
"problems" :
 1 - in the implementation, trying to compare values from different
groups raises an error instead of simply returning "False" (easy to fix ...)
 2 - You have to declare these enumerable variables, which is not
pythonic IMO (impossible to fix ... needs complete redesign)

In the end, I really think symbols and enum are of different use, one of
the interest un symbols being to let the compiler does what he wants
(i.e. probably what is the most efficient).

Thanks for your reply,

Pierre