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

PEP 786: Precision and Modulo-Precision Flag format specifiers for integer fields#4416

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

Open
jb2170 wants to merge19 commits intopython:main
base:main
Choose a base branch
Loading
fromjb2170:pep-786-precision

Conversation

@jb2170
Copy link

@jb2170jb2170 commentedMay 8, 2025•
edited
Loading

New rebased PR with the correct branch name to avoid confusion (786 not 791).

Thank you Alyssa for sponsoring this!

Relevant discussions, issues, PRs linked

Basic requirements (all PEP Types)

  • Read and followedPEP 1 &PEP 12
  • File created from thelatest PEP template
  • PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) andPEP header
  • Title clearly, accurately and concisely describes the content in 79 characters or less
  • Core dev/PEP editor listed asAuthor orSponsor, and formally confirmed their approval:@ncoghlan
  • Author,Status (Draft),Type andCreated headers filled out correctly
  • PEP-Delegate,Topic,Requires andReplaces headers completed if appropriate: Is a PEP-Delegate required?
  • Required sections included
    • Abstract (first section)
    • Copyright (last section; exact wording from template required)
  • Code is well-formatted (PEP 7/PEP 8) and is incode blocks, with the right lexer names if non-Python: everything but 80-column line length, so as to avoid tedious re-aligning during this draft stage
  • PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
  • Authors/sponsor added to.github/CODEOWNERS for the PEP

Standards Track requirements

  • PEP topicdiscussed in a suitable venue with general agreement that a PEP is appropriate
  • Suggested sections included (unless not applicable)
    • Motivation: included in Rationale
    • Rationale
    • Specification: Abstract is RFC 2119 style
    • Backwards Compatibility
    • Security Implications: not needed?
    • How to Teach This: Examples And Teaching section
    • Reference Implementation
    • Rejected Ideas
    • Open Issues: None so far
  • Python-Version set to valid (pre-beta) future Python version, if relevant
  • Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such: none
  • Right before or after initial merging,PEP discussion thread created and linked to inDiscussions-To andPost-History

📚 Documentation preview 📚:https://pep-previews--4416.org.readthedocs.build/pep-0786/

@jb2170jb2170 requested a review froma team as acode ownerMay 8, 2025 01:09
@AA-TurnerAA-Turner added the new-pepA new draft PEP submitted for initial review labelMay 8, 2025
@AA-TurnerAA-Turner requested a review fromncoghlanMay 8, 2025 01:19
Copy link
Member

@AA-TurnerAA-Turner left a comment

Choose a reason for hiding this comment

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

I haven't read the content of the PEP yet, but a few notes:

jb2170 reacted with thumbs up emoji
It's better to give the formatspec one canonical ordering than permit anoverly liberal rearrangeability.If commutativity were added, then as well as the messy description requiredfor the docs for the particular case of `int` data, two people could writetwo different format spec that result in the same output and not realiseit or agree, because they've written different things, leading to confusion etc.
jb2170and others added6 commitsMay 16, 2025 07:47
I'll address the other ones in a separate commit(s)Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
I'm the author of this PEP. Sergey and Raymond shouldn't be pestered over it. They are in the appropriate 'Thanks' section.
skirpichev
skirpichev previously requested changesMay 16, 2025
Thank you to

* Sergey B Kirpichev, for discussions and implementation code.
* Raymond Hettinger, for the initial suggestion of the two's complement behavior.
Copy link
Contributor

Choose a reason for hiding this comment

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

Again, Raymond's initial suggestion was very different from proposed here: when value not fits to the two's complement format - error should be raised. In fact, it's now in "Rejected Alternatives", if I have read this huge text correctly.

I suggest you to either drop everything, related to specific handling of thez flag, or ask@rhettinger if he is ok with proposed here behavior (i.e.z will be an alias tovalue % 2**prec for'b' type, no errors or anything else to indicate that value not fits).

Copy link
Author

Choose a reason for hiding this comment

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

@rhettinger do you want to be included in the Thanks section? Yoursuggestion was part of the basis of thez flag in this PEP.

The main difference is that we don't raise aValueError for 'out of range integers' since the modular arithmetic is more of a feature than a bug!

Copy link
Author

Choose a reason for hiding this comment

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

I'll leave it in

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, it's not just about "thanks".

So far, your new handling of the'z' flag backed only by Raymond's feature request. But it's not clear if this issue was solved as author expected. Meanwhile, I suggest moving proposal for the'z' flag to the Open Issues section.

Copy link
Contributor

@skirpichevskirpichev left a comment

Choose a reason for hiding this comment

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

Disclaimer: My English, probably, is horrible. Perhaps, it was the reason why this text looks too difficult for me to follow and understand. Anyway, here my 2c as PEP reader.

The PEP text is huge, c.f. PEP 682 (roughly half of this). While it's idea (even with optional extension for'z' flag) looks damn simple. I think the text win if you address this issue.

Also, you might consider to better follow to standard section meanings. E.g. "Rationale" should describe why particular design decisions were made. While "Motivation" - why we need proposed features at all. "Specification", "Rejected Ideas", etc.

I also suggest to move'z' flag proposal to the "Open Issues" section. It was very briefly discussed in the ideas thread, not backed by existing feature requests and proposed specification clearly contradicts to the C behavior.

when formatting an integer with precision and one of the binary, octal, or
hexadecimal presentation types (bases that are powers of two). This first
reduces the integer into ``range(base ** precision)`` using the ``%`` operator.
The result is a predictable two's complement style formatting with the *exact*
Copy link
Contributor

Choose a reason for hiding this comment

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

two's complement style formatting

What that means?

Comment on lines +261 to +262
We endeavor to conclude in the following section that the former camp, lossless
formatting, has no use cases, and is thus a rejected idea, whence this PEP
Copy link
Contributor

Choose a reason for hiding this comment

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

has no use cases

It's just not true. All your C examples demonstrate that. As well, as issuepython/cpython#74756.

"Use case" is simple and obvious: to show two's complement value, not something "like" (that has no mathematical meaning).

value of ``-2 ** (n-1)``, to ``+2 ** (n-1)``, with a new ``n+1``\th column of
value ``-2 ** n`` prefixed on, the overall sum unaffected.

This is what C's ``printf`` does, working with powers of two as the numbers of digits:
Copy link
Contributor

Choose a reason for hiding this comment

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

You might note, that "b" format type is available since the C23. (Works for me with-std=c2x one recent gcc.)

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

Reviewers

@hugovkhugovkhugovk left review comments

@skirpichevskirpichevskirpichev left review comments

@AA-TurnerAA-TurnerAA-Turner left review comments

@StanFromIrelandStanFromIrelandStanFromIreland left review comments

@ncoghlanncoghlanAwaiting requested review from ncoghlan

Assignees

No one assigned

Labels

new-pepA new draft PEP submitted for initial review

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@jb2170@hugovk@skirpichev@AA-Turner@StanFromIreland
[8]ページ先頭
©2009-2025 Movatter.jp