Re: Why keep identity-based equality comparison?

Antoon Pardon <apardon@xxxxxxxxxxxxxxx> writes:
>> Yes. Searching for items in heterogenous containers. With your change
>> in place, the "in" operator becomes pretty much worthless on
>> containers of heterogenous objects. Ditto for container methods that
>> do searches for "equal" members. Whenever you compare two objects that
>> don't have the same type, you'll get an exception and terminate the
>> search. If the object your searching for would have been found
>> "later", you lose - you'll get the wrong answer.
> Maybe that is just a wrong implementation of the "in" operator.

That's what I said just below:

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

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

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

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

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

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

Relevant Pages

  • Re: Why keep identity-based equality comparison?
    ... >> equality operator for Py3K, ... exception the same as the two elements not being equal. ... class which originally raised an exception when comparing values ... is just meaningless and using such an object in a container ...
    (comp.lang.python)
  • Re: Why keep identity-based equality comparison?
    ... >>> that it will raise an exception if they pass it incomparable types? ... >> class which originally raised an exception when comparing values ... It is broken in the context of the current python behaviour. ... >> is just meaningless and using such an object in a container ...
    (comp.lang.python)
  • Re: Enumeration idioms: Values from different enumerations
    ... >>> whole point of enumerations is to avoid errors in such cases. ... >> if a specific enum value is in the list, and the obvious way to check ... >> exception - it takes a relatively convoluted bit of code to make this ... > What's being discussed here is what happens when comparing the *values* ...
    (comp.lang.python)
  • Re: Expression: map/set iterators incompatible
    ... after going back and looking through the code again, we see that comparing an iterator with NULL will always through an exception. ... If you are looking for an iterator which says that you are not accessing anything valid, it should be set to the end of the container to which the iterator belongs and you can check if it is accessing a valid value by writing "if )". ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Why keep identity-based equality comparison?
    ... >>> of different types throw an exception by default or none does. ... It presumes that all operators of all types either always ... > order in finding an element from a container. ... able to override the order function for some specific method (and ...
    (comp.lang.python)