[Armin Rigo]
Your float.richcompare patch, trying to map the C semantics at the Python level, introduces artificial results when comparing NaN's with longs:
Not really. All Python behavior in the presence of NaNs was accidental before. That it remains accidental was noted in the checkin comment, and in an XXX block in the new code. The specific form of accidents may or may not have changed, depending on platform.
float('nan') > 0
And it remains an accident that float('nan') didn't raise ValueError on whatever box you're using (it does, e.g., on mine).
False
float('nan') > 0L True
I am not aware of all the problems and various platforms, but clearly in the patch 'vsign' by itself doesn't make much sense if 'v' is a NaN.
Right, it makes no sense.
Wouldn't all compilers and platforms compare NaNs "strangely", for some detectable definition of "stange"?
Yes. Some may even raise SIGFPE if you try; that was also true before the patch.
Something along the lines of:
#define Py_IS_NAN(v) (!Py_IS_INFINITY(v) && \ ( ((v) < 0.0 && (v) > 0.0) || \ !((v) < 1.0 || (v) > -1.0) )
As the new code says, /* XXX If we had a reliable way to check whether i is a * XXX NaN, it would belong in this branch too. */ The best candidate for 2.4 may be: #define Py_IS_NAN(v) ((v) != (v)) That works under MS VC 7.1, but didn't work under VC 6.0 (which is why the "for 2.4" qualifier -- Python on Windows is switching to 7.1 for 2.4). If someone can confirm that it works under recent gcc too, let's do that. Nothing exists that will work on all platforms, but all platforms claiming to support 754 have *some* way to spell "true iff a NaN, and don't raise SIGFPE just because I'm asking". C99 spells that isnan(x), from math.h. MS C doesn't have that, but does have _isnan(x), from float.h. That's the maddening part -- it's easy to spell on any specific platform, but nothing about the spelling (neither name nor header file) is the same across platforms.