Antoon Pardon <[EMAIL PROTECTED]> writes: >> 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.
That's what I said just below: >> 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. Yes, I remember. I also remember that it was eventually agreed that that Enum behavior was broken. > 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. I claim that comparing for equality is *never* meaningless. Either two objects are equal, or they aren't. It may be that they are of different types - like the enum example above - in which case they will never compare equal. Note that this is different from an ordering. It's possible to have a pair of objects - maybe even of the same type - that can't be ordered in anyway. In this case, raising an exception when you try that comarison makes sense. >> 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. > But there are certainly circumstances that I would prefer 1 == (1,2) > to throw an exception instead of simply turning up False. So what are they? > 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. Nothing wierd about that at all. Anyone who's dealt with floats at all should be used to it. > I think such cases can be troublesome too for containers and the > "in" operator. I don't. Can you provide an example of where it is? > IMO some more thinking about this is needed before deciding this > would be a good idea or not. Actually, what's need are examples of usages where breaking equality into two (or more - most LISPs have three different definitions of equality) different relations is usefull. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list