Guido van Rossum wrote:
It's not about equality. If you ask whether two NaNs are *unequal* the answer is *also* False.
That's the weirdest part about this whole business, I think. Unless you're really keeping your wits about you, it's easy to forget that the assumption (x == y) == False implies (x != y) == True doesn't necessarily hold. This is actually a very important assumption when it comes to reasoning about programs -- even more important than reflexivity, etc, I believe. Consider if x == y: dosomething() else: dosomethingelse() where x and y are known to be floats. It's easy to see that the following is equivalent: if not x == y: dosomethingelse() else: dosomething() but it's not quite so easy to spot that the following is *not* equivalent: if x != y: dosomethingelse() else: dosomething() This trap is made all the easier to fall into because float comparison is *mostly* well-behaved, except for a small subset of the possible values. Most other nonstandard comparison behaviours in Python apply to whole types. E.g. we refuse to compare complex numbers for ordering, even if their values happen to be real, so if you try that you get an early exception. But the weirdness with NaNs only shows up in corner cases that may escape testing. Now, there *is* a third possibility -- we could raise an exception if a comparison involving NaNs is attempted. This would be a more faithful way of adhering to the IEEE 754 specification that NaNs are "unordered". More importantly, it would make the second code transformation above valid in all cases. So the question that really needs to be answered, I think, is not "Why is NaN == NaN false?", but "Why doesn't NaN == anything raise an exception, when it would make so much more sense to do so?" -- Greg