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:
>>> 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.
>
> Yes, I remember. I also remember that it was eventually agreed that
> that Enum behavior was broken.

It is broken in the context of the current python behaviour.
In a different context with different behaviour of containers
such behaviour may very well be the most intuitive.

We are now talking about python3k and so such we should
be open to the possibility that what is broken in
current python may very well be desirable behaviour for
what python will evolve into.

>> 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.

If you take the first choice you are right that comparing for
equality is never meaningless, but so is using the other comparisons.
If two objects are not comparable then we just have that a < b, a ==b
and a > b are all false.

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.

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.

>>> 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?
>
>> 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.

>> I think such cases can be troublesome too for containers and the
>> "in" operator.
>
> I don't. Can you provide an example of where it is?

Well not with the "in" operator but with the index method of lists
which seems related enough.

If the "in" operator returns true one can use index to find out
an element in the container that compares equal. Now normally
it wouldn't make a difference whether you would make further
comparisons against the original object or against the object
in the list. But in this case it can make a difference and
it isn't obvious what one should do.

>> IMO some more thinking about this is needed before deciding this
>> would be a good idea or not.
>
> Actually, what's need are examples of usages where breaking equality
> into two (or more - most LISPs have three different definitions of
> equality) different relations is usefull.

I think it is usefull because when I am looking for 1 in a list,
I'm not necessarily happy when I find 1.0 or decimal("1").

-- 
Antoon Pardon