[Python-ideas] checking for identity before comparing built-in objects
Guido van Rossum
guido at python.org
Mon Oct 8 18:25:16 CEST 2012
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.
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas