Why keep identity-based equality comparison?

[Christopher Subich]

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.

In languages that allow operator overloading, there are always some 
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 
argument that operator overloading is unclear; Python accepts the 
occasional ambiguity and allows (indeed encourages, to a reasonable 
degree) operator overloading for conciseness and expressiveness.


To reply to your other argument, Antoon:
> 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,...)), 
to badly mangle the syntax).