# Why keep identity-based equality comparison?

Christopher Subich csubich.spam.block at spam.subich.block.com
Tue Jan 10 10:21:07 EST 2006

```Antoon Pardon wrote:
> Op 2006-01-10, Peter Decker schreef <pydecker at gmail.com>:

>>I don't see the two comparisons as equivalent at all. If two things
>>are different, it does not follow that they can be ranked.
>
>
> That a < b returns false doesn't imply that a and b can be ranked.
> take sets. set([1,2]) and set([1,3)) can't be ranked but
> set([1,2]) < set([1,3)) returns False just as set([1,2]) > set([1,3))
> does.

Breaking my resolution already, but you're ignoring the fact that the
set type uses the '<' and '>' operators from a set-theoretic, not
number-theoretic point of view.  Saying "set(1,3) is greater than
set(1,2)" is meaningless (and not false), because the mathematical basis
of the operator in this context is superset -- "set(1,3) is a superset
of set(1,2)" is well-defined and false.

Set uses '<' and '>' because the superset and subset symbols aren't on
the keyboard.

well-defined cases where the operator is the simplest, clearest notation
yet the operator has a meaning very distinct from the arithmetical
operation.  As another example, Pyparsing uses '<<' to "load" a Forward
declaration, for recursive grammars -- this obviously has nothing to do
with bit-shifting.

Of course, cases like these two are fairly textbook examples for the
occasional ambiguity and allows (indeed encourages, to a reasonable

> 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.
[snip]
> 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").

I personally feel that the use cases for this "other" comparison (===?)
are very restricted.  In fact, your example itself isn't even a use-case
for this operator, because integer/float/decimal have well-defined
equality comparisons already (that explicitly account for different
types) -- the implicit "not is implies !=, if __eq__ isn't defined"
behaviour isn't triggered.

The use-case for a "===" operator would seem to be restricted to when
program behaviour is determined soley by "a" not equalling "b."  If a
"wrong" object is referenced by "b," then the program might do a Bad
Thing, because it expects "b" to be something else... except that the
error would be caught later anyway -- probably by calling "b.method()"
or somesuch.

In fact, even in more esoteric cases the behaviour of "==" as-is is
useful; in the itertools.izip_longest discussion, this behaviour is
implicitly used in the sentinel-stopping method
(izip(chain(iter,sent),chain(iter,sent),...,stop=(sent,sent,sent,...)),