[Python-Dev] Why is nan != nan?

[Adam Olsen]

On Sat, Mar 27, 2010 at 18:27, Robert Kern <robert.kern at gmail.com> wrote:
> On 2010-03-27 13:36 , Adam Olsen wrote:
>> What's the flaw in using isnan()?
>
> There are implicit comparisons being done inside list.__contains__() and
> other such methods. They do not, and should not, know about isnan().

Those methods should raise an exception.  Conceptually, NaN should
contaminate the result and make list.__contains__() return some
"unsortable", but we don't want to bend the whole language backwards
just for one obscure feature, especially when we have a much better
approach most of the time (exceptions).

The reason why NaN's current behaviour is so disturbing is that it
increases the mental load of everybody dealing with floats.  When you
write new code or debug a program you have to ask yourself what might
happen if a NaN is produced.  When maintaining existing code you have
to figure out if it's written a specific way to get NaN to work right,
or if it's even a fluke that NaN's work right, even if it was never
intended for NaNs or never sees them on developer machines.  This is
all the subtlety we work so hard to avoid normally, so why make an
exception here?  NaNs themselves have use cases, but their subtlety
doesn't.


-- 
Adam Olsen, aka Rhamphoryncus