Why keep identity-based equality comparison?

[Fuzzyman]

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.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml