Re: Why keep identity-based equality comparison?

Mike Meyer wrote:

>> My question is, what reasons are left for leaving the current default
>> equality operator for Py3K, not counting backwards-compatibility?
>> (assume that you have idset and iddict, so explicitness' cost is only
>> two characters, in Guido's example)
>
> 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.
>
> 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?
>
> 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. I'd say breaking that
> is a bad thing. But if you don't break that, then having "x == y"
> raise an exception for user classes seems wrong. The comparison should
> be False unless they are the same object - which is exactly what
> equality based on id gives us.

Seconded. All hell would break loose if Python didn't allow == for heterogenous
types, $DEITY only knows how many types I relied on it. Please don't let it go
in Py3k.
--
Giovanni Bajo


.

Relevant Pages

  • Re: Why keep identity-based equality comparison?
    ... > equality operator for Py3K, ... Whenever you compare two objects that ... you'll get an exception and terminate the ... every container type now has this split between identity and ...
    (comp.lang.python)
  • 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?
    ... >>> is just meaningless and using such an object in a container ... > exception in this case, but it doesn't matter much which test you are ... Can you provide a case where having a test for equality throw an ... Comparators - including equality comparators - can already throw ...
    (comp.lang.python)
  • Re: collection framework: using the good interface
    ... The word object's class would implement Comparable, and should have equals and hashCode consistent with compareTo, but I would not make two words equal unless they are, in all respects, the same word. ... I'm more and more convinced that equality should involve all aspects of the Word class, but I'm still uncomfortable with mixing lexicographic information (allowing to compare objects in different collections) and information about frequency, distribution, cooccurrents. ...
    (comp.lang.java.help)
  • Re: If statement
    ... i want to compare atabsin equality ... or call the function atabs passing in the argument i ... since that value is *not* non-zero, ...
    (comp.soft-sys.matlab)