Why keep identity-based equality comparison?

[Antoon Pardon]

Op 2006-01-10, Mike Meyer schreef <mwm at mired.org>:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>>>> 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.
>> IMO you have the choice between taking the mathematical route or
>> the practical route.
>
> The behavior proposed for Py3k *is* the practical route. It gives a
> reasonable behavior, and one that leads to simple implemenations for
> container operations.

Then I have to ask, practical for who, user of python or the
implementor, because I don't find it practical that a language
says at the same times that two objects can use a comparision
and can't.

>> Now you can take the practical option and decide that programmatically
>> it make no sense to compare a specific couple of values and throw an
>> exception in this case, but it doesn't matter much which test you are
>> conducting at that point.
>
> Can you provide a case where having a test for equality throw an
> exception is actually useful?

I'm not going to bother with that. Sure uses cases are interesting
but if you always wait for a use case before implementing something,
whatever the other arguments are, you will disappoint the future
people with a use case because they can't do what they want yet.

I haven't seen a case where testing for unequality throwing an
exception would be actually usefull, yet that is considered,
why do I have to provide a use case.

> BTW, the case you're arguing for is *different* from the case the OP
> proposed. By my reading, he wanted equality testing to throw an
> exception for two objects unless a comparison was explicitly coded. So
> that even a == a could cause an exception.

Why not? If a is of a type where == is a meaningless operation then
a == a is meaningless too.

>> Maybe python should adopt both approaches and introduce a new family
>> of comparators. Then one family will always succeed and the other
>> family can throw an exception.
>
> Comparators - including equality comparators - can already throw
> exceptions. The enum case proved that.

Your point? Your remark says nothing for or against python having
two families of comparators, one that is defined as never throwing
an exception and one defined as exception throwable.

>>>>> 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?
>
> Again - give us real use cases.

I didn't see a real use case for 1 < (1,2) throwing an exception either.
The only argument seems to be that the current behaviour confuses
beginners. But I don't see that as such a strong argument because
a number of other things confuse beginners too and are not up
for a change. I also think that 1 == (1,2) returning False but
1 < (1,2) throwing an excpetion masy not be that less confusing
as the current behaviour.

I don't care that much what it will be, but I would prefer a consistent
approach for all comparators. No either all throw an exception when
the two operands are of differnt type or None does (or two families)

>>>> 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.
>> With floats that is entirely a problem of precision. When you are
>> working with discrete types such circumstances remain weird.
>
> Floats *are* a discrete type. The equality *relationship* is what's
> fuzzy. There are lots of non-transitive relationships around. I don't
> find them wierd at all.

That there are a lot of non-transitive relationships and that there
is nothing weird about them, says nothing about one specific
relationship, == which normaly is considered to be transitive
and turns out not to be.

Beside I think the == comparison is transitive on the floats. It
is just that if you do your calculations that the imprecision in
the numbers can give you a result that give false where you expect
true when comparing for equality, but that is because you got
a different float as a result than you expected, not because
the float == relationship is not transitive.

-- 
Antoon Pardon