Why keep identity-based equality comparison?

[Antoon Pardon]

Op 2006-01-10, Fuzzyman schreef <fuzzyman_no at spam_voidspace.org.uk>:
> On 9 Jan 2006 14:40:45 -0800, spam.noam at gmail.com wrote:
>
>>Hello,
>>
>>Guido has decided, in python-dev, that in Py3K the id-based order
>>comparisons will be dropped. This means that, for example, "{} < []"
>>will raise a TypeError instead of the current behaviour, which is
>>returning a value which is, really, id({}) < id([]).
>>
>>He also said that default equality comparison will continue to be
>>identity-based. This means that x == y will never raise an exception,
>>as is the situation is now. Here's his reason:
>>
>>> Let me construct a hypothetical example: suppose we represent a car
>>> and its parts as objects. Let's say each wheel is an object. Each
>>> wheel is unique and we don't have equivalency classes for them.
>>> However, it would be useful to construct sets of wheels (e.g. the set
>>> of wheels currently on my car that have never had a flat tire). Python
>>> sets use hashing just like dicts. The original hash() and __eq__
>>> implementation would work exactly right for this purpose, and it seems
>>> silly to have to add it to every object type that could possibly be
>>> used as a set member (especially since this means that if a third
>>> party library creates objects for you that don't implement __hash__
>>> you'd have a hard time of adding it).
>>
>>Now, I don't think it should be so. My reason is basically "explicit is
>>better than implicit" - I think that the == operator should be reserved
>>for value-based comparison, and raise an exception if the two objects
>>can't be meaningfully compared by value. If you want to check if two
>>objects are the same, you can always do "x is y". If you want to create
>>a set of objects based on their identity (that is, two different
>>objects with the same value are considered different elements), you
>>have two options:
>
> I often want to be able to ask, is one object equal to another, where
> they *might* be of the same type or notr.
>
> If they aren't of the same type,  then the answer to :
>
> 	a == b
>
> is obviously False. Otherwise I have to wrap the test in a
> ``try...except`` block or compare type (and possibly then compare
> value). Both of which are more verbose.

If we are going to stick to one equal comparator then there will
always be cases that seem to be more verbose than needed. In the
case where you consider it an error if you are working with objects
of different classes you now have to expicitely test for unequal
types and raise an exception explicitly which is also more verbose. 

IMO if they aren't of the same type then the answer to:

  a < b

is just as obviously False as

  a == b

Yet how things are proposed now, the first will throw an exception
and the latter will return False.

-- 
Antoon Pardon