[Python-Dev] Why is nan != nan?
steve at pearwood.info
Sun Mar 28 23:17:25 CEST 2010
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>
> > 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
+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.
More information about the Python-Dev