My guess is that no one ever bothered to define hash(nan), which should, IMHO, be nan.

nan isn't anything. It's an early attempt at None when no/few (common) languages had that concept.

That python allows nan as an index is just so many kinds of buggy.

For binary operations, NaN values compare as unordered.

The IEEE 754 Specification requires that >,<,= evaluate to False.

Saying that two incomparable objects become comparable let alone gain equally would break things.

We use specific exponents and significands to represent NaNs but they have no numerical meaning.

I am actually surprised python got this correct, often NaN behavior is incorrect out of convenience and causes lots of issues and side effects.

At the standards level, NaN payload propagation isn't guaranteed, regardless of any other issues.

The hash is the same. But a hash set has to use == in case of equal hashes (to avoid collisions).

Probably just due to encoding. NaN is all 1s for the exponent and non-zero mantissa, so that's 2^23 - 1 possible values for f32