gh-130662: accept leading zeros in precision/width for Fraction's formatting

[skirpichev]

• Issue: format(Fraction(1, 3), '.016f') raises ValueError #130662

[skirpichev]

CC @ericvsmith per experts index

[serhiy-storchaka]

LGTM.

I have some minor suggestions for tests.

[gvanrossum]

Note that there's another inconsistency between float and Fraction.

x=1/3f"{x:_>010f}"# '__3.140000', ignores the zero-padx=Fraction(1, 3) Traceback (mostrecentcalllast): File"<python-input-4>", line1, in<module>f"{x:_>010f}"^^^^^^^^^^File"/Users/guido/cpython/Lib/fractions.py", line600, in__format__raiseValueError( ...<2lines>... ) ValueError: Invalidformatspecifier'_>010f'forobjectof 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?

[skirpichev]

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

[gvanrossum]

As happens occasionally, the docs are out of sync with the implementation, and we should respond by updating the docs, not the code. IMO.

[skirpichev]

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.

[gvanrossum]

Okay, I will leave it to more active core devs to sort out.

[skirpichev]

Alternative pr: #130717

[vstinner]

LGTM. I agree with @serhiy-storchaka: #130662 (comment)

[miss-islington-app]

Thanks @skirpichev for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[bedevere-app]

GH-135026 is a backport of this pull request to the 3.14 branch.

[vstinner]

Merged, thank you.

GH-135026 is a backport of this pull request to the 3.14 branch.

I disagree: we should not backport this change to stable branches.

[picnixz]

Wasn't it a fix for something we introduced in 3.14? @skirpichev

[vstinner]

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.

[skirpichev]

I disagree: we should not backport this change to stable branches.

Why not? It's a bug, isn't?

[vstinner]

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.

[skirpichev]

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.

[serhiy-storchaka]

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.

[miss-islington-app]

Thanks @skirpichev for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[bedevere-app]

GH-136361 is a backport of this pull request to the 3.14 branch.