gh-114667: Support hexadecimal floating-point literals

[skirpichev]

This add hexadecimal floating-point literals (IEEE 754-2008 §5.12.3) and support construction of floats from hexadecimal strings. Note that the syntax is more permissive: everything that is currently accepted by the float.fromhex(), but with a mandatory base specifier; it also allows grouping digits with underscores.

Examples:

>>> 0x1.1p-1
0.53125
>>> float('0x1.1')
1.0625
>>> 0x1.1
1.0625
>>> 0x1.1_1_1
1.066650390625

Using hexadecimal floating-point literals allow us directly construct exact arbitrary floating-point values, which was available before via float.fromhex() class method. The later is less convenient, especially doing interactive work.

This also could be used by some projects in the python ecosystem to provide multiple precision binary floating-point arithmetic in CLI interface: hexadecimal floating-point numbers now are valid tokens and can be wrapped by appropriate type, e.g. gmpy2.mpfr. See the Decimal math example on how it's possible with decimal floating-point numbers.

Minor changes:

• Py_ISDIGIT/Py_ISXDIGIT macros were transformed to functions (see Convert Py_ISDIGIT/ISXDIGIT/etc to inline functions? #114047 and gh-108767: Convert Py_ISLOWER() macro to static inline function #108770)

---

Notes

As now it's requires a PEP, here is a PEP draft.

Open issues:

• Should the exponent part be mandatory?
• Should we change the float constructor? This doesn't make much sense in the current version, where the exponent is optional.
• Should we adapt tests to use hexadecimal literals instead of more verbose float.fromhex()?
• Should we deprecate float.fromhex()?

Complementary PR: #113805 (formatted output)

---

• Issue: Support hexadecimal floating point literals #114667

---

📚 Documentation preview 📚: https://cpython-previews--114668.org.readthedocs.build/

[skirpichev]

Now it is ready for review. The second commit should clear syntax incompatibility wrt access to public attributes on hexadecimal integer literals, e.g. 0x1.to_bytes.

One note for reviewers (also valid for #113805, but more relevant here): do we still support non-IEEE 754 platforms? Build requirements claims: "Support for IEEE 754 floating point numbers and floating point Not-a-Number (NaN)." is required.

The current pr has special case, using the system strtod() if _PY_SHORT_FLOAT_REPR == 0. This was tested locally on IEEE system. But will this be tested by some CPython's build bot (hardly it's tested by regular GA checks)? More generally, is there reasons (after 10+ years) to not use system's strtod() (in C locale) to do hard work?

[pablogsal]

This needs a PEP accepted before it can be reviewed

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[skirpichev]

PEP Draft and pr were updated to match each other. I'll convert this pr to a draft if one will touch some new files.