[Python-Dev] cmp(x,x) (original) (raw)

Tim Peters tim.one at comcast.net
Fri May 21 15:21:09 EDT 2004

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

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

More information about the Python-Dev mailing list