Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
vstinner merged 5 commits intopython:mainfromskirpichev:fix-fmt-fractions/130662
Jun 2, 2025

Conversation

skirpichev
Copy link
Contributor

@skirpichevskirpichev commentedFeb 28, 2025•
edited by bedevere-appbot
Loading

@skirpichev
Copy link
ContributorAuthor

CC@ericvsmith per experts index

Copy link
Member

@serhiy-storchakaserhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

LGTM.

I have some minor suggestions for tests.

Copy link
Member

@gvanrossumgvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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
Copy link
ContributorAuthor

skirpichev commentedMar 1, 2025•
edited
Loading

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
Copy link
Member

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
Copy link
ContributorAuthor

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
Copy link
Member

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

@skirpichev
Copy link
ContributorAuthor

Alternative pr:#130717

Copy link
Member

@vstinnervstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@skirpichevskirpichev changed the titlegh-130662: make Fraction's formatting more compatible wrt float'sgh-130662: accept leading zeros in precision/width for Fraction's formattingApr 15, 2025
@skirpichevskirpichev added the 3.14bugs and security fixes labelApr 28, 2025
@skirpichevskirpichev added needs backport to 3.14bugs and security fixes and removed 3.14bugs and security fixes labelsMay 8, 2025
@skirpichevskirpichev requested a review frompicnixzJune 2, 2025 06:29
@skirpichevskirpichev requested a review frompicnixzJune 2, 2025 11:39
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
@vstinnervstinner merged commit5bc2d99 intopython:mainJun 2, 2025
39 checks passed
@miss-islington-app
Copy link

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

miss-islington pushed a commit to miss-islington/cpython that referenced this pull requestJun 2, 2025
…'s formatting (pythonGH-130663)(cherry picked from commit5bc2d99)Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
@bedevere-app
Copy link

GH-135026 is a backport of this pull request to the3.14 branch.

@bedevere-appbedevere-appbot removed the needs backport to 3.14bugs and security fixes labelJun 2, 2025
@vstinner
Copy link
Member

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
Copy link
Member

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

@vstinner
Copy link
Member

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.

picnixz reacted with thumbs up emoji

@skirpichev
Copy link
ContributorAuthor

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

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

@skirpichevskirpichev deleted the fix-fmt-fractions/130662 branchJune 2, 2025 13:56
@vstinner
Copy link
Member

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
Copy link
ContributorAuthor

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 currentformatting specification mini-language or use more strict rules? This was coming frommpmath/mpmath#915.

@serhiy-storchaka
Copy link
Member

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.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@gvanrossumgvanrossumgvanrossum left review comments

@serhiy-storchakaserhiy-storchakaserhiy-storchaka approved these changes

@vstinnervstinnervstinner approved these changes

@picnixzpicnixzpicnixz approved these changes

Assignees
No one assigned
Labels
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

5 participants
@skirpichev@gvanrossum@vstinner@picnixz@serhiy-storchaka
[8]ページ先頭
©2009-2025 Movatter.jp