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

Ned Batchelder ned at nedbatchelder.com
Mon Oct 8 04:35:17 CEST 2012


On 10/7/2012 9:51 PM, Guido van Rossum wrote:
> On Sun, Oct 7, 2012 at 6:09 PM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>> On Sun, Oct 7, 2012 at 8:54 PM, Guido van Rossum <guido at python.org> wrote:
>>> Seriously, we can't change our position on this topic now without
>>> making a lot of people seriously unhappy. IEEE 754 it is.
>> I did not suggest a change.  I wrote: "I am not suggesting any
>> language changes, but I think it will be
>> useful to explain why float('nan') != float('nan') somewhere in the
>> docs."  If there is a concise explanation for the choice of IEEE 754
>> vs. Java, I think we should write it down and put an end to this
>> debate.
> Referencing Java here is absurd and I still consider this suggestion
> as a troll. Python is not in any way based on Java.
>
> On the other hand referencing IEEE 754 makes all the sense in the
> world, since every other aspect of Python float is based on IEEE 754
> double whenever the underlying platform implements this standard --
> and all modern CPUs do. I don't think there's anything else we need to
> say.
>
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.

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."

--Ned.



More information about the Python-ideas mailing list