Proposal for adding symbols within Python

Ben Finney bignose+hates-spam at benfinney.id.au
Sun Nov 13 18:54:40 EST 2005


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?

> 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.

> 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.

> 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.

> 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.

> 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.

-- 
 \       "My aunt gave me a walkie-talkie for my birthday. She says if |
  `\     I'm good, she'll give me the other one next year."  -- Steven |
_o__)                                                           Wright |
Ben Finney



More information about the Python-list mailing list