> It doesn't (at the moment).

Sorry; that was an unhelpful kneejerk reply.

There are two aspects to this. (1) Currently, at least in theory, CPython doesn't require IEEE 754 *at all*:  in theory, it should work with whatever floating-point format the platform's "double" type happens to provide.  In practice I suspect there's a lot more IEEE 754 dependence in the codebase than we realize, and I'd expect to see a fair amount of test breaking if Python were ever to meet a non-IEEE 754 platform.  (Reports of any *recent* occurrences of Python in the wild meeting non-IEEE 754 platforms would be welcomed.)

(2) If CPython *does* figure out that it's running on an IEEE 754 platform then yes, care should be taken with compiler flags to ensure that we're not using compiler optimisations that have the potential to break IEEE semantics.  Without this there's a significant danger of float to string conversions getting messed up;  there are also a few odds and ends in the math and cmath libraries that depend on careful IEEE semantics.  (The implementations of fsum and log1p, for example.)

I think the right fix here is to add the relevant compiler flag to the build.  That said, I'd *also* love to see remaining uses of Py_NAN fixed to use _Py_dg_stdnan where available.