[Python-Dev] PyObject_RichCompareBool identity shortcut

[Terry Reedy]

On 4/27/2011 10:53 AM, Guido van Rossum wrote:
> On Wed, Apr 27, 2011 at 7:39 AM, Raymond Hettinger

 >> Identity-implies-equality is necessary so that classes can maintain 
 >> their invariants and so that programmers can reason about their code.
[snip]
>>   See http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ for
>> a nice blog post on the subject.

I carefully reread this, with the comments, and again came to the 
conclusion that the committee left us no *good* answer, only a choice 
between various more-or-less unsatifactory answers. The current Python 
compromise may be as good as anything. In any case, I think it should be 
explicitly documented with an indexed paragraph, perhaps as follows:

"The IEEE-754 committee defined the float Not_a_Number (NaN) value as 
being incomparable with all others floats, including itself. This 
violates the math and logic rule that equality is reflexive, that 'a == 
a' is always True. And Python collection classes depend on that rule for 
their proper operation. So Python makes the follow compromise. Direct 
equality comparisons involving Nan, such as "NaN=float('NaN'); NaN == 
ob", follow the IEEE-754 rule and return False. Indirect comparisons 
conducted internally as part of a collection operation, such as 'NaN in 
someset' or 'seq.count()' or 'somedict[x]', follow the reflexive rule 
and act as it 'Nan == NaN' were True. Most Python programmers will never 
see a Nan in real programs."

This might best be an entry in the Glossary under "NaN -- Not a Number". 
It should be the first reference for Nan in the General Index and linked 
to from the float() builtin and float type Nan mentions.

> Maybe we should just call off the odd NaN comparison behavior?

Eiffel seems to have survived, though I do not know if it used for 
numerical work. I wonder how much code would break and what the scipy 
folks would think. 3.0 would have been the time, though.

-- 
Terry Jan Reedy