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.
| >>> f"{x:#08b}" | ||
| '0b001100' # we wanted 8 bits, not 6 :( | ||
|
|
||
| One could attempt to argue that since the length of a prefix is known to always be 2, it can be accounted for manually by adding 2 to the desired number of digits. Consider however the following demonstrations of why this is a bad idea: |
There was a problem hiding this comment.
| One could attempt to argue that since the length of a prefix is known to always be 2, it can be accounted for manually by adding 2 to the desired number of digits. Consider however the following demonstrations of why this is a bad idea: | |
| One could attempt to argue that since the length of a prefix is known to always be two, it can be accounted for manually by adding two to the desired number of digits. Consider however the following demonstrations of why this is a bad idea: |
There was a problem hiding this comment.
Since this PEP is heavy with arithmetic I'm hesitant to replace numerals (2) with their formal English version (two) for the sake of legibility and flow in the appropriate paragraphs. I'm aware of the convention in English to write numbers 0-9 formally, but this is a technical specification.
Sometimes (like in the line being reviewed here) we also use 'one' as an indefinite pronoun, and so it seems reasonable to keep the numbers in arithmetic contexts separate as numerals. Otherwise 'one' and 'two' being present in this sentence looks misleading.
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. |
There was a problem hiding this comment.
| * Sergey B Kirpichev, for discussions and implementation code. | |
| * Sergey B Kirpichev, for discussions and implementation code. |
Please remove me from Thanks. My implementation was very different from the proposed here, which I think is a bad idea.
| 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).
New rebased PR with the correct branch name to avoid confusion (786 not 791).
Thank you Alyssa for sponsoring this!
There is a
TODOsection in the PEP that shall perish as the PEP is tweaked before acceptingRelevant 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 relevant: pendingDiscussions-ToandPost-History📚 Documentation preview 📚: https://pep-previews--4416.org.readthedocs.build/pep-0786/