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

[Steven D'Aprano]

On Sun, 28 Mar 2010 05:32:46 pm Adam Olsen wrote:
> 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).

I disagree -- if I ask:

3.0 in [1.0, 2.0, float('nan'), 3.0]

I should get True, not an exception. Comparing NANs for equality isn't 
an error.

+1 on leaving the behaviour alone -- the surprising behaviour people 
have pointed out with NANs in lists, dicts and sets occurs more often 
in theory than in practice. 



-- 
Steven D'Aprano