It would be more satisfying to learn why hash of nan is not guaranteed to be the same. It feels like a bug.
Yes and no:
`If an operation has a single NaN input and propagates it to the output, the result NaN's payload should be that of the input NaN (this is not always possible for binary formats when the signaling/quiet state is encoded). If there are multiple NaN inputs, the result NaN's payload should be from one of the input NaNs; the standard does not specify which.'
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.
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.
>>> hash(float('nan'))
271103401
>>> hash(float('nan'))
271103657