Why keep identity-based equality comparison?

[Antoon Pardon]

Op 2006-01-10, Mike Meyer schreef <mwm at mired.org>:
> spam.noam at gmail.com 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