[Python-Dev] Rich comparisons (original) (raw)

Michael Hudson mwh at python.net
Fri Mar 19 07:01:31 EST 2004

"Raymond Hettinger" <python at rcn.com> writes:

[Guido] > (The best scheme is probably to use intern() but still use '==' for > comparisons; '==' is smart enough to skip comparing an object to > itself.) [Tim] Well, stringrichcompare() takes that shortcut, so the advice is good, but PyObjectRichCompare() doesn't in general (PyObjectCompare() still does, but that's not triggered by '=='). Hey, hey, this may be part of the answer to why my timings for equality testing using rich comparisions run so much slower than they do with PyObjectCompare().

How much is 'so much'? When I recently implemented rich comparisons for floats, there was no change in performance that I could discern (apart from comparing floats to integers which sped up by ~30%).

Fixing this would entail a change in semantics but would be worth it if we can all agree to it.

Bzzt!, then:

float('nan') nan == False

while this is well into the realm of 'platform specific accidents', it is somewhat desirable. And will happen in 2.4 on linux, OS X and Windows as things currently stand (so at a guess 90%+ of Python installs).

[...]

I think the change is worth it -- tests for equality are ubiquitous (and somewhat common) throughout the source.

But how often are they between identical objects?

Cheers, mwh

-- If I had wanted your website to make noise I would have licked my finger and rubbed it across the monitor. -- signature of "istartedi" on slashdot.org

More information about the Python-Dev mailing list