Michael <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list