PEP 786: Precision and Modulo-Precision Flag format specifiers for integer fields#4416
PEP 786: Precision and Modulo-Precision Flag format specifiers for integer fields#4416jb2170 wants to merge 22 commits intopython:mainfrom
Conversation
AA-Turner
left a comment
There was a problem hiding this comment.
I haven't read the content of the PEP yet, but a few notes:
It's better to give the formatspec one canonical ordering than permit an overly liberal rearrangeability. If commutativity were added, then as well as the messy description required for the docs for the particular case of `int` data, two people could write two different format spec that result in the same output and not realise it or agree, because they've written different things, leading to confusion etc.
I'll address the other ones in a separate commit(s) Co-authored-by: Hugo van Kemenade <[email protected]>
…lutter in the format specification
I'm the author of this PEP. Sergey and Raymond shouldn't be pestered over it. They are in the appropriate 'Thanks' section.
The new Abstract given by d477f4c seems sufficient.
No example needed for non-hardware aware modulo Remove the '[sic]' since we're not quoting Sergey.
skirpichev
left a comment
There was a problem hiding this comment.
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.
|
Where are we up to with this PEP? |
|
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 |
|
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. |
|
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. |
Co-authored-by: Hugo van Kemenade <[email protected]>
Co-authored-by: Hugo van Kemenade <[email protected]>
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)
pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) andPEPheaderAuthororSponsor, and formally confirmed their approval: @ncoghlanAuthor,Status(Draft),TypeandCreatedheaders filled out correctlyPEP-Delegate,Topic,RequiresandReplacesheaders completed if appropriate: Is a PEP-Delegate required?.github/CODEOWNERSfor the PEPStandards Track requirements
Python-Versionset to valid (pre-beta) future Python version, if relevantDiscussions-ToandPost-History📚 Documentation preview 📚: https://pep-previews--4416.org.readthedocs.build/pep-0786/