gh-130662: accept leading zeros in precision/width for Fraction's formatting #130663
Conversation
|
CC @ericvsmith per experts index |
There was a problem hiding this comment.
Note that there's another inconsistency between float and Fraction.
x = 1/3
f"{x:_>010f}" # '__3.140000', ignores the zero-pad
x = Fraction(1, 3)
Traceback (most recent call last):
File "<python-input-4>", line 1, in <module>
f"{x:_>010f}"
^^^^^^^^^^
File "/Users/guido/cpython/Lib/fractions.py", line 600, in __format__
raise ValueError(
...<2 lines>...
)
ValueError: Invalid format specifier '_>010f' for object of type 'Fraction'So we still fail the goal of Fraction supporting everything that float does. Since Fraction actually is more strict (which is the way of the future) aren't we fixing this the wrong way?
|
Here is implementation pr, for context: #100161 The ValueError raised in case both alignment (and the fill character) and zero padding are specified on the ground "refuse the temptation to guess". In principle, it's not hard to reproduce float's behavior (zero padding is ignored if the fill character is specified). Though, maybe it's better to align this with the Fraction instead. Probably, it's a separate issue. Edit: #130716 Few another incompatibilities: #130664 |
|
As happens occasionally, the docs are out of sync with the implementation, and we should respond by updating the docs, not the code. IMO. |
|
The problem is that the stdlib has several beasts (Decimal and Fraction), that have slightly different implementations of new-style formatting. IMO, documenting all these differences will make documentation much less readable. Also, it's less obvious to which convention should follow external modules, like the mpmath or the gmpy2. |
|
Okay, I will leave it to more active core devs to sort out. |
|
Alternative pr: #130717 |
Misc/NEWS.d/next/Library/2025-06-02-14-28-30.gh-issue-130662.EIgIR8.rst
Outdated
Show resolved
Hide resolved
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
Thanks @skirpichev for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14. |
…'s formatting (pythonGH-130663) (cherry picked from commit 5bc2d99) Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
GH-135026 is a backport of this pull request to the 3.14 branch. |
|
Merged, thank you.
I disagree: we should not backport this change to stable branches. |
|
Wasn't it a fix for something we introduced in 3.14? @skirpichev |
No, Python 3.13 has the same behavior for example. It was "always" like that. @skirpichev proposed to have the behavior for all types: float, Fraction, Decimal. Before, only float accepted leading zeros. |
Why not? It's a bug, isn't? |
From my point of view, it's a new feature and existing projects may rely on the current (Python 3.14) behavior. |
How?! The issue is about formatting stdlib types (Fractions and Decimals, in a separate pr). Should external projects use current formatting specification mini-language or use more strict rules? This was coming from mpmath/mpmath#915. |
|
From my point of view, this is a borderline between a minor feature and an unsignificant bug fix which we may not want to backport. So maybe to 3.14 only? The solved problem is rather scholastic. |
Uh oh!
There was an error while loading. Please reload this page.