PEP 786: Precision and Modulo-Precision Flag format specifiers for integer fields #4416
Conversation
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 <1324225+hugovk@users.noreply.github.com>
…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.
| Thank you to | ||
|
|
||
| * Sergey B Kirpichev, for discussions and implementation code. | ||
| * Raymond Hettinger, for the initial suggestion of the two's complement behavior. |
There was a problem hiding this comment.
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 the z flag, or ask @rhettinger if he is ok with proposed here behavior (i.e. z will be an alias to value % 2**prec for 'b' type, no errors or anything else to indicate that value not fits).
There was a problem hiding this comment.
@rhettinger do you want to be included in the Thanks section? Your suggestion was part of the basis of the z flag in this PEP.
The main difference is that we don't raise a ValueError for 'out of range integers' since the modular arithmetic is more of a feature than a bug!
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.
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/