Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Ben Finney a écrit :
> Michael <ms at cerenity.org> wrote:
> 
>>Ben Finney wrote:
>>
>>>I've yet to see a convincing argument against simply assigning
>>>values to names, then using those names.
>>
>>If you have a name, you can redefine a name, therefore the value a
>>name refers to is mutable.
> 
> 
> Since there are mutable and immutable values, it might be clearer to
> say "the binding of a name to a value can be changed". Yes?
> 
> In that case, I don't see why someone who wants such a binding to be
> unchanging can't simply avoid changing it. Where's the case for having
> Python enforce this?
> 

The problem is not about having something constant !
The main point with symbols is to get human-readable values.
Let say you have a symbol "opened" and a symbol "closed". The state of a
file may be one of the two.

If you have these symbols, you can ask for the state at any point and
get something readable. If you use constants valued, typically, to
integers, the state of your file will we 0 or 1, which does not mean
anything.

Now, if you're using an object with more than two states, and moreover
if the number of states is likely to increase during developpement, it's
much more convenient to directly get the *meaning* of the value rather
than the value itself (which does not mean anything).

The key point that, I think, you misunderstand is that symbols are not
*variables* they are *values*.

> 
>>Conversely consider "NAME" to be a symbol. I can't modify "NAME". It
>>always means the same as "NAME" and "NAME", but is never the same as
>>"FRED". What's tricky is I can't have namespaceOne."NAME" [1] and
>>namespaceTwo."NAME" as different "NAME"s even though logically
>>there's no reason I couldn't treat "NAME" differently inside each.
> 
> 
> So you want to mark such objects as being in a namespace, where they
> compare the same within that namespace but not outside. Why is
> separate syntax necessary for this? A data type that is informed of
> its "space", and refuses comparison with values from other spaces,
> would suffice.
> 
>     class Xenophobe(object):
>         def __init__(self, space, value):
>             self.__space = space
>             self.__value = value
> 
>         def __str__(self):
>             return str(self.__value)
> 
>         def __cmp__(self, other):
>             if not isinstance(other, Xenophobe):
>                 raise AssertionError, \
>                     "Can only compare Xenophobes to each other"
>             if not other.__space == self.__space:
>                 raise AssertionError, \
>                     "Can only compare Xenophobes from the same space"
>             return cmp(self.__value, other.__value)
> 
> With the bonus that you could pass such values around between
> different names, and they'd *still* compare, or not, as you choose
> when you first create them.
> 
> Replace the AssertionError with some appropriate return value, if you
> want such comparisons to succeed.
> 

Well, I think a new syntax will promote the use of symbols. And as I
think they are good practice (much better than meaningless constants)
they should be promoted. Needless to say that in every language I know
implementing symbols (or something close to symbols), there is an
easy-to-use syntax associated.

> 
>>However it might be useful to note that these two values (or
>>symbols) are actually different, even if you remove their
>>namespaces.
> 
> 
> The above Xenophobe implementation creates objects that know their
> "space" forever.
> 
> 
>>To me, the use of a symbol implies a desire for a constant, and then
>>to only use that constant rather than the value. In certain
>>situations it's the fact that constant A is not the same as constant
>>B that's important (eg modelling state machines).
> 
> 
> Since the actual value can't be easily accessed, the only purpose of a
> Xenophobe is too be created and compared to others.
> 
> 
>>Often you can use strings for that sort of thing, but unfortunately
>>even python's strings can't be used as symbols that are always the
>>same thing in all ways. For example, we can force the id of
>>identical strings to be different:
> 
> 
> Hold up -- what in your stated use case requires *identity* to be the
> same? You said you just wanted to compare them to each other.
> 
> Besides, Python *does* preserve identity for short strings...
> 
> 
>>>>>s = "h"*10000
>>>>>x = "h"*10000
>>>>>id(s), id(x)
>>
>>(135049832, 135059864)
> 
> 
> ... which is sufficient for unique values, if you're not actively
> fighting the system as above. If the use case is for brief, identical
> values, we have those: short strings.

Well, one *big* difference between short string and symbols is that the
identity between short strings are implementation dependant, while
between symbols it has to be in all implementations as you will rely on
this identity. Then, once more, strings are just one possible
implementation for symbols and I wouldn't like to tie that much symbols
to strings.

>>As a result I can see that *IF* you really want this kind of symbol,
>>rather than the various other kinds people have discussed in the
>>thread, that some special syntax (like u'hello' for unicode 'hello')
>>could be useful.
> 
> 
> I can see the case for a new type. I disagree that syntax changes are
> necessary.
> 

Well, syntactic sugar is all about what you want to promote or
discourage ... it is never necessary, even if it can really be usefull.

> 
>>However, I'd be more interested in some real world usecases where
>>this would be beneficial, and then seeing what sort of syntax would
>>be nice/useful (Especially since I can think of some uses where it
>>would be nice).
> 
> 
> Real use cases would interest me, too, but *only* if they can't be
> satisfied with a new type that knows things about its creation state,
> such as Xenophobe.
> 

Well, once more, new syntax for new objects never solve new problems,
they just make them easier to write.

> 
>>The reason I'm more interested in seeing usecases, is because I'd
>>rather see where the existing approaches people use/define symbols
>>has caused the OP problems to the extent he feels the language needs
>>to change to fix these real world problems.
> 
> 
> Ditto.
> 

Pierre