[Python-Dev] cmp(x,x)

[Tim Peters]

[Armin Rigo]
> Ok, then the current situation looks like the best one.  I suggest we
> just drop a note in the documentation saying that if there are objects
> for which x.__eq__(x) isn't necessarily true, you shouldn't expect them
> to be handled in a fully consistent way.

If that's *all* we say, it's not really helpful, is it?  Besides, __eq__()
isn't even required to return a truth value.  If we believe the CPython
implementation is correct, then the truth is more that the implementation is
allowed to return True for

    x == y

if

    x is y

is true, regardless of what x.__eq__(y), y.__eq__(x), x.__cmp__(y) or
y.__cmp__(x) would do if called directly.

If that's what we really mean, then better to say that.  It then sounds
exactly like the cheap-ass micro optimization it is <wink>.

[Michael Chermside]
>> But wouldn't your> performance problems be fixed just as well if the
>> tuple class implemented "identical-objects-are-immediately-equal"
>> instead of putting it in the general comparison logic for all objects?
>> Because if I understand correctly, that's what Armin is suggesting.
>> Tuples would still be compared just as rapidly.

> There is an extra costly indirection until the execution reaches that
> point.

Well, gasoline is costly, and so is a Mercedes-Benz.  Michael was replying
to a fellow worried about factor-of-2 slowdowns.  The indirection here isn't
in that ballpark of expense.  Still, it's not worth any expense unless it's
useful.

NaN comparison is a red herring not only because Python doesn't have a sane
story in any area involving NaNs, but also because the 32 possible 754
comparison predicates can't be mapped onto 6 operator symbols.  Note that in
C99, the infix C relational operators raise an exception (754's "invalid
operation") when applied to a NaN, and C99 adds a pile of new macros for
non-exceptional NaN comparison (my favorite is the fetchingly named
"islessgreater(x, y)" -- which "is similar to (x) < (y) || (x) > (y);
however, islessgreater(x,y) does not raise the invalid exception when x and
y are unordered (nor does it evaluate x and y twice)").

In a sane design for handling NaNs, it's important that the "legacy"
comparison operators raise an exception in their presence, because code
written under the assumption of trichotomy is a bug minefield when unordered
NaNs become possible comparands.

In short, if Python ever wants "correct" NaN comparison, it needs to add new
operators or functions too.