Open skirpichev opened 6 months ago
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
Normally, to reduce the noise PRs and issues are submitted after a PEP is approved.
@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.
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
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.
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 viafloat.fromhex()
andfloat.hex()
methods, which extensively used in it's test suite (e.g. to testmath
andrandom
modules). But using the class method to create exact floating point values much less convenient, especially doing interactive work: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