Skip to content

Commit bd29ea4

Browse files
committed
Remove TODO bullet point for z and # commutativity
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.
1 parent 3ca6120 commit bd29ea4

File tree

1 file changed

+0
-5
lines changed

1 file changed

+0
-5
lines changed

peps/pep-0786.rst

Lines changed: 0 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -346,11 +346,6 @@ TODO AND REMOVE BEFORE MERGE
346346
* RFC 2119 Style Specification? After all is said and done here.
347347
* Add Sergey and Raymond to the authors field, or is Thanks enough?
348348
* Give a good example of non-hardware aware use of modular arithmetic formatting, my brain has gone blank...
349-
* Possibly (probably not) add one more feature to the PEP:
350-
351-
Loosening :pep:`682`\ 's strict ordering of ``[#][z]`` as they appear in the `format specification <formatspec_>`_ for ``int`` fields for readability. (Or is this just my taste?: debate this)
352-
353-
The existing `format specification <formatspec_>`_ mandates that if both ``z`` and ``#`` are to be used, they must appear in that order, leading to ``z#.``, with ``z`` separated from its ``.``, however this could be changed to be more permissible if there are no syntax clashes, to permit ``#z.``, or is this just my taste? :pep:`682` proposed / uses ``[sign][z]`` instead of ``[sign[z]]``, which has given us the opportunity to reuse ``z``, and really has no strict need to be ``[sign][z][#]...[.precision]``, or are we doing too much voodoo by allowing ``z`` and ``#`` to commute with each other, even if it's just for ``int`` fields. I'm starting to think this might be too much voodoo.
354349

355350

356351
Footnotes

0 commit comments

Comments
 (0)