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.
python · jb2170 · Apr 11, 2025 · May 6, 2025 · May 8, 2025 · May 8, 2025
commit bd29ea463001810179d7280ee1489203b4ab71c6
@@ -346,11 +346,6 @@ TODO AND REMOVE BEFORE MERGE
 * RFC 2119 Style Specification? After all is said and done here.
 * Add Sergey and Raymond to the authors field, or is Thanks enough?
 * Give a good example of non-hardware aware use of modular arithmetic formatting, my brain has gone blank...
-* Possibly (probably not) add one more feature to the PEP:
-
-  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)
-
-  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.
 
 
 Footnotes