Why keep identity-based equality comparison?

[Mike Meyer]

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.

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

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.

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

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

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

The index method of list is already a bit fuzzy.

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

That's because in this case there's no on "right" answer. What you
should do will depend on what you are trying to accomplish. That's the
normal state of affairs when programming.

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

That's an argument for a more *precise* equality operator. That's
certainly worth considering, but has nothing to do with whether or not
it makes sense for an equality comparison to throw an exception.

   <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.