Hello Tim, On Tue, May 18, 2004 at 11:24:50PM -0400, Tim Peters wrote:

...

...

...

...

float('nan') is float('nan') False

That result simply isn't defined, even on platforms where float('nan') doesn't blow up: floats are immutable objects, and outside of interning strings, Python doesn't define anything about the identity of immutable objects returned from computation.

Ok, I won't go into that argument again then. Raymond told me that the PyObject_RichCompareBool() short-cut is essential for performance, as a very large number of internal comparisons end up comparing identical objects (e.g. with dicts). I don't really care about what occurs with float('nan'), but it seems marginally strange that the outcome could, with some compilers, depend on the way you compare them: even though x == x and cmp(x,x) are known to do different things, as rich comparison goes, you wouldn't expect this to show up with floats. But anyway that's fine by me (and could be easily fixed by patching float_compare and float_richcompare to check for identity). A slightly stranger irregularity (though not a problem in general) is that comparing two objects of user-defined classes may invoke neither the __cmp__ nor the __eq__ special method at all. It should at least be documented somewhere, in my opinion. The language reference currently explicitely states that x==y calls x.__eq__(y) and falls back to y.__eq__(x). Armin