[Python-Dev] PyObject_RichCompareBool identity shortcut (original) (raw)

Terry Reedy tjreedy at udel.edu
Wed Apr 27 19:44:30 CEST 2011

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

More information about the Python-Dev mailing list