更新：自从我在下面写了最初的答案，情况有了轻微的变化。CPython版本3.11和更高版本现在要求平台C double遵循IEEE 754 binary 64格式。这主要是为了方便开发人员-它允许我们删除在实践中接近不可测试的特殊情况代码。Python语言仍然没有规定IEEE 754是必需的，并且没有什么可以阻止某人修补CPython以添加对不遵循IEEE 754的不寻常平台的支持;将结果称为“Python”仍然是合理的。此外，即使对于CPython，也没有文件保证格式将是IEEE 754 binary 64-开发人员可以决定颠倒IEEE 754 binary 64要求。（我个人认为，至少在未来十年内，这是极不可能发生的，但这是可能的。
理论上，正如你所说的，CPython被设计成可以在任何平台上构建和使用，而不关心他们的C double使用的是什么浮点格式。
在实践中，有两件事是正确的：

• 据我所知，在过去的15年里，CPython还没有遇到过一个不使用IEEE 754 binary 64格式的C double的系统（尽管我很想听到相反的故事;我已经在会议上问了一段时间了）。我的知识离完美还有很长的路要走，但在这15年中，我至少有13年参与了CPython核心开发的数学和浮点相关方面的工作，并在那段时间里密切关注浮点相关的问题。我在bug跟踪器或其他地方没有看到任何迹象表明有人试图在使用IEEE 754 binary 64以外的浮点格式的系统上运行CPython。
• 我强烈怀疑现代CPython * 第一次遇到这样的系统时，会有大量的测试失败，因此核心开发人员可能会很快发现它。虽然我们已经努力使事情与格式无关，但目前几乎不可能在其他格式上对CPython进行任何测试，并且很可能有一些地方隐含地假设IEEE 754格式或语义，这将打破更奇特的东西。我们还没有看到任何此类破损的报告。

有一个例外，上面的“没有错误报告”报告。是这个问题：https://bugs.python.org/issue27444。在那里，Greg Stark报告说，使用VAX浮点确实存在故障。我不清楚最初的错误报告是否来自模拟VAX浮点的系统。
我于2008年加入CPython核心开发团队。当时，当我在处理浮点相关的问题时，我试图记住5种不同的浮点格式：IEEE 754 binary 64，IBM在其zSeries大型机中使用的十六进制浮点格式，SV 1和更早的机器中使用的Cray浮点格式，以及VAX D-float和G-float格式;其他的一切都太古老了，不值得担心。从那时起，VAX格式不再值得关注。Cray机器现在使用IEEE 754浮点。IBM十六进制浮点格式仍然存在，但在实践中，相关的IBM硬件 * 也 * 支持IEEE 754，Python遇到的IBM机器似乎都在使用IEEE 754浮点。
现代的挑战似乎更多地与遵守IEEE 754标准的其余部分的变化有关，而不是外来的浮点格式：不支持NaN的系统，或以不同方式处理次法线，或允许对中间操作使用更高精度，或编译器进行行为更改优化的系统。
以上都是关于CPython的实现，而不是Python的语言。但Python语言的情况大致相似。理论上，它不对浮点格式做任何假设。在实践中，我不知道有任何替代的Python实现最终不使用IEEE 754二进制格式（如果不是语义的话）来处理float类型。IronPython和Jython都以明确表示浮点数将是IEEE 754 binary 64的运行时为目标。基于JavaScript的Python版本同样可能使用JavaScript的Number类型，ECMAScript标准要求该类型为IEEE 754 binary 64。PyPy运行在与CPython几乎相同的平台上，具有相同的浮点格式。MicroPython对float类型使用单精度，但据我所知，实际上仍然是IEEE 754 binary 32。