Support hexadecimal floating point literals

[skirpichev]

Feature or enhancement

Proposal:

The Python supports only decimal floating point literals. But underlying hardware based floating point numbers are binary, not decimal, and conversion to and from decimal representation is delicate: it's not obvious which binary floating point number represent a given decimal literal.

Exact floating point representations are especially important for reproducible results --- for instance, while testing "borderline cases" in algorithms. Because of this, many contemporary languages (e.g. C, Go, Julia, Java) introduce hexadecimal floating point literals in source code. This format also common in the numerical analysis community (see e.g. this example or the MPFR library).

Lets accept exact floating point literals (beyond simple cases like 0.25) as first-class citizens in the language! Right now the Python include support for hexadecimal floats via float.fromhex() and float.hex() methods, which extensively used in it's test suite (e.g. to test math and random modules). But using the class method to create exact floating point values much less convenient, especially doing interactive work:

>>> float.fromhex('0x1.ffffp10')
2047.984375
>>> 0x1.ffffp10
2047.984375
>>> -0x1p-1074
-5e-324
>>> 0x1.1
1.0625
>>> float('0x1.1')
1.0625

As it was noted in the discussion thread, this feature might require a PEP. In this case I'm looking for a sponsor. Meanwhile, I'll make a draft pr, to not trigger review requests.

PEP draft: https://github.com/skirpichev/peps/pull/3

Related issue: https://github.com/python/cpython/issues/113804

Has this already been discussed elsewhere?

I have already discussed this feature proposal on Discourse

Links to previous discussion of this feature:

https://discuss.python.org/t/41848

Linked PRs

• gh-114668

[skirpichev]

114668 is ready for review

[pablogsal]

Hi @skirpichev and thanks for the proposal. Unfortunately a change of this magnitude needs a PEP. Please read about it https://devguide.python.org/developer-workflow/lang-changes/#suggesting-new-features-and-language-changes

[pablogsal]

Normally, to reduce the noise PRs and issues are submitted after a PEP is approved.

[skirpichev]

@pablogsal, perhaps I misunderstood suggestion in the discussion thread (that this change may require a PEP), i.e. "should" was interpreted per RFC2119.

The PEP draft was presented in the discussion thread (though it not reflects now the shape of the pr, which uses more float.fromhex()-compatible syntax; but it could be updated).

Should I close pr and issue?

PS: Sorry for the noise.

[pablogsal]

Should I close pr and issue?

No, now that is open leave it. I have already mentioned in the PR that until a PEP is accepted it should not be merged. This is just a suggestion for the future. This is because the specification of the PR may change quite a lot before it's accepted, so reviewing it it's not super useful.

@pablogsal, perhaps I misunderstood suggestion in the discussion thread (that this change may require a PEP), i.e. "should" was interpreted per RFC2119.

Not sure I understand what you mean by this. This change requires a PEP because it's changing the grammar, so you need to follow the PEP process before we can get it merged

[skirpichev]

Not sure I understand what you mean by this.

I meant reply by Mark Dickinson.

This change requires a PEP because it's changing the grammar

Perhaps, I misunderstood something in the above reference, but it doesn't have a strict requirement for a PEP in case of grammar changes. My guess was that it might be the case, if the feature could be implemented without backward incompatible changes.

Sorry, and thank you for a clarification.