Op 2006-01-10, Mike Meyer schreef <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] writes: >> My question is, what reasons are left for leaving the current default >> equality operator for Py3K, not counting backwards-compatibility? >> (assume that you have idset and iddict, so explicitness' cost is only >> two characters, in Guido's example) > > Yes. Searching for items in heterogenous containers. With your change > in place, the "in" operator becomes pretty much worthless on > containers of heterogenous objects. Ditto for container methods that > do searches for "equal" members. Whenever you compare two objects that > don't have the same type, you'll get an exception and terminate the > search. If the object your searching for would have been found > "later", you lose - you'll get the wrong answer.
Maybe that is just a wrong implementation of the "in" operator. One may agree on a protocol for the "in" operator to catch the TypeError when it tests for equality and treating the raised exception the same as the two elements not being equal. > You could fix this by patching all the appropriate methods. But then > how do you describe their behavior, without making some people expect > that it will raise an exception if they pass it incomparable types? But that is already a problem. Remember the thread about the Enum class which originally raised an exception when comparing values from different Enums. This would already cause such a problem. There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the "in" operator. > Also, every container type now has this split between identity and > equality has to be dealt with for *every* container class. If you want > identity comparisons on objects, you have to store them in an idlist > for the in operator and index methods to work properly. > I also think your basic idea is wrong. The expression "x == y" is > intuitively False if x and y aren't comparable. I'm not that sure about the "intuitively". The author of the Enum class didn't seem to find it that intuitive to just name one counter example. IMO "x == y" turning up false when uncomparable is just as intuitive as "x < y" turning up false when uncomparable but a lot of people don't seem to agree with the latter. My impression is that what is intuitive may vary wildly here. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. I think such cases can be troublesome too for containers and the "in" operator. IMO some more thinking about this is needed before deciding this would be a good idea or not. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
