See "[Python-Dev] Should we require IEEE 754 floating-point for CPython?" thread:
https://mail.python.org/archives/list/python-dev@python.org/thread/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/

I propose to require IEEE 754 floating-point to build Python 3.11. I propose the following build:

• Mention the new build requirement in What's New in Python 3.11.
• Modify configure script to make it fail if the IEEE 754 support is missing.
• Remove code handling missing NAN and infinity: float("nan"), float("inf"), math.nan and math.inf are always available.
• Remove @requires_IEEE_754 decorator of test.support and tests.
• Remove "unknown_format" code path of pack/unpack functions like _PyFloat_Pack8() (see bpo-46906 which proposes to make these functions public).

The _PY_SHORT_FLOAT_REPR==0 code path is kept. For now, platforms with float larger than 64-bit but without HAVE_PY_SET_53BIT_PRECISION are still supported (but don't get "short float repr"). See #75773 for details.

I prepared this requirement with these two changes:

commit 1b2611e
Author: Victor Stinner <vstinner@python.org>
Date: Fri Feb 25 01:32:57 2022 +0100

bpo-46656: Remove Py_NO_NAN macro (GH-31160)

Building Python now requires support for floating point Not-a-Number
(NaN): remove the Py_NO_NAN macro.

commit 5ab745f
Author: Victor Stinner <vstinner@python.org>
Date: Sat Feb 26 00:53:27 2022 +0100

bpo-46852: Remove the float.__set_format__() method (GH-31585)

Remove the undocumented private float.__set_format__() method,
previously known as float.__set_format__() in Python 3.7. Its
docstring said: "You probably don't want to use this function. It
exists mainly to be used in Python's test suite."

By the way, building Python 3.11 now requires a C11 compiler.

• Mention the new build requirement in What's New in Python 3.11.
• Modify configure script to make it fail if the IEEE 754 support is missing.
• Remove code handling missing NAN and infinity: float("nan"), float("inf"), math.nan and math.inf are always available.

That sounds fine.

• Remove @requires_IEEE_754 decorator of test.support and tests.

I'd suggest leaving those decorators. Some of the tests are used by Python implementations other than CPython, and we're not requiring IEEE 754 on all Python implementations.

• Remove "unknown_format" code path of pack/unpack functions like _PyFloat_Pack8() (see bpo-46906 which proposes to make these functions public).

Sounds fine.

platforms with float larger than 64-bit

I'm assuming you mean Python "float" / C "double" here. There seems to be a persistent misunderstanding here, and I'd really like to be sure that everyone understands what the current code is doing before changing anything. There are *no* platforms that Python cares about where the C double is larger than 64-bits, and as far as I'm aware there never have been.

What there *is* is a set of platforms where the C double is IEEE 754 binary64 format, but where arithmetic operations between doubles may be performed in extended precision (usually 64-bit precision), so those arithmetic operations don't conform strictly to IEEE 754 semantics. Most flavours of Linux on x86 match that description.

Then there's a (possibly empty, but we don't know that for sure) subset of *that* set of platforms where we don't know how to temporarily enforce 53-bit precision during numeric parsing / formatting operations.

It's that second subset where dtoa.c can't be used, and where we need the fallback of the "legacy" float repr.

I'd be more than happy to deprecate and eventually remove support for the legacy float repr, but I think it's too big a change to make for 3.11: we'd need to deprecate the support for 3.11 and eventually remove it in 3.13.

New changeset 9b51fd5 by Victor Stinner in branch 'main':
bpo-46917: Require IEEE 754 to build Python (GH-31790)
9b51fd5

See also bpo-46906 "Add PyFloat_(Pack|Unpack)(2|4|8) to the public C API": the implementation supports non-IEEE 754 formats. Once the public C API is added, support for non-IEEE 754 formats should be removed.

New changeset 7854012 by Victor Stinner in branch 'main':
bpo-46917: math.nan is now always available (GH-31793)
7854012

bpo-46917: math.nan is now always available (GH-31793)

Technically, it was already the case in practice: see bpo-46656 for the rationale and the history of Py_NAN.

Remove code handling missing NAN and infinity: float("nan"), float("inf"), math.nan and math.inf are always available.

The code to support missing NaN was already removed by:

New changeset 1b2611e by Victor Stinner in branch 'main':
bpo-46656: Remove Py_NO_NAN macro (GH-31160)
1b2611e

In fact, math.inf is already always available in Python 3.10 and older. There was no "#ifdef" for missing infinity support. In Python 3.10, math.inf is implemented as:

static double
m_inf(void)
{
#ifndef PY_NO_SHORT_FLOAT_REPR
    return _Py_dg_infinity(0);
#else
    return Py_HUGE_VAL;
#endif
}

@vstinner Can this be closed?

I still would like to:

Remove "unknown_format" code path of pack/unpack functions

Remove "unknown_format" code path of pack/unpack functions

Sorry but I failed to find the bandwidth to get ride of this code, so I will just close the issue.

If someone wants to work on that, please go ahead and write a PR and maybe open a new dedicated issue (specific to this).

At least, the main part, requiring IEEE 754 to build Python, is implemented in Python 3.11! It's written in What's New in Python 3.11 ;-)