Why keep identity-based equality comparison?

[Giovanni Bajo]

Mike Meyer wrote:

>> 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.
>
> 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?
>
> 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'd say breaking that
> is a bad thing. But if you don't break that, then having "x == y"
> raise an exception for user classes seems wrong. The comparison should
> be False unless they are the same object - which is exactly what
> equality based on id gives us.

Seconded. All hell would break loose if Python didn't allow == for heterogenous
types, $DEITY only knows how many types I relied on it. Please don't let it go
in Py3k.
-- 
Giovanni Bajo