Why keep identity-based equality comparison?

[Mike Meyer]

Antoon Pardon <apardon at forel.vub.ac.be> 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 <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.