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

[jb2170]

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

• https://discuss.python.org/t/implement-precision-format-spec-for-int-type-data/80760
• gh-74756: support precision field for integer formatting types cpython#131926
• Add integer formatting code for fixed-width signed arithmetic (2's complement) cpython#74756
• [Old] PEP 786: Precision and Modulo-Precision Flag format specifiers for integer fields #4365

Basic requirements (all PEP Types)

• Read and followed PEP 1 & PEP 12
• File created from the latest PEP template
• PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) and PEP header
• Title clearly, accurately and concisely describes the content in 79 characters or less
• Core dev/PEP editor listed as Author or Sponsor, and formally confirmed their approval: @ncoghlan
• Author, Status (Draft), Type and Created headers filled out correctly
• PEP-Delegate, Topic, Requires and Replaces 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 in code 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 topic discussed 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 in Discussions-To and Post-History

---

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

[AA-Turner]

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

ok

[skirpichev]

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.

[hugovk]

Where are we up to with this PEP?

[jb2170]

All it needs is the reference implementation and it's ready imo.

I got frustrated with skirpichev not understanding the intended modular arithmetic behaviour / two's complement / C integer types wrapping, and so I left this PEP stagnant, but I have thought about it at least once a day for the past several months now!

I'll have a go at the implementation. It's my first time dealing with Python's C code so do double check if I use a Py_INCREF instead of Py_XINCREF etc 😅

[hugovk]

OK, good luck! Keep in mind there's two months until the 3.15 feature freeze, so this would need to be merged/discussed/submitted to SC/accepted/implemented before then. But there's always 3.16 after that.

[jb2170]

Reference implementation section added, all set.

The reference implementation itself is at python/cpython#146437

I'll rebase it off of the main branch tomorrow (unless it's easier to read as-is?).

Everything seems ready.

[hugovk]

@ncoghlan As sponsor, please could you give this a review before we merge and kick off the discussion?