[Python-ideas] checking for identity before comparing built-in objects

Ned Batchelder ned at nedbatchelder.com
Mon Oct 8 22:39:52 CEST 2012


On 10/8/2012 12:25 PM, Guido van Rossum wrote:
> On Sun, Oct 7, 2012 at 7:35 PM, Ned Batchelder <ned at nedbatchelder.com> wrote:
>> I don't understand the reluctance to address a common conceptual speed-bump
>> in the docs.  After all, the tutorial has an entire chapter
>> (http://docs.python.org/tutorial/floatingpoint.html) that explains how
>> floats work, even though they work exactly as IEEE 754 says they should.
> I'm sorry. I didn't intend to refuse to document the behavior. I was
> mostly reacting to things I thought I read between the lines -- the
> suggestion that there is no reason for the NaN behavior except silly
> compatibility with an old standard that nobody cares about. From this
> it is only a small step to reading (again between the lines) the
> suggesting to change the behavior.
>
>> A sentence in section 5.4 (Numeric Types) would help.  Something like, "In
>> accordance with the IEEE 754 standard, NaN's are not equal to any value,
>> even another NaN.  This is because NaN doesn't represent a particular
>> number, it represents an unknown result, and there is no way to know if one
>> unknown result is equal to another unknown result."
> That sounds like a great addition to the docs, except for the nit that
> I don't like writing the plural of NaN as "NaN's" -- I prefer "NaNs"
> myself. Also, the words here can still cause confusion. The exact
> behavior is that every one of the 6 comparison operators (==, !=, <,
> <=, >, >=) returns False when either argument (or both) is a NaN. I
> think your suggested words could lead someone to believe that they
> mean that x != NaN or NaN != Nan would return True.
>
> Anyway, once we can agree to words I agree that we should update that section.
>
How about:

"In accordance with the IEEE 754 standard, when NaNs are compared to any value, even another NaN, the result is always False, regardless of the comparison.  This is because NaN represents an unknown result.  There is no way to know the relationship between an unknown result and any other result, especially another unknown one.  Even comparing a NaN to itself always produces False."

--Ned.




More information about the Python-ideas mailing list