[Python-Dev] Why is nan != nan? (original) (raw)

Steven D'Aprano 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> 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

More information about the Python-Dev mailing list