Restructure section about two cases of truncation

No example needed for non-hardware aware modulo Remove the '[sic]' since we're not quoting Sergey.
python · jb2170 · Apr 11, 2025 · May 6, 2025 · May 8, 2025 · May 8, 2025
commit 045df95ef5c88ed625758e5b3691b12ab7bf40cf
@@ -301,39 +301,35 @@ the desired behavior. Formally we may say that the formatting should be a well
 defined bijection between the equivalence classes of ``Z/(base ** precision)Z``
 and strings with ``precision`` digits.
 
-The remaining question is "[sic] is there no chance to communicate this
-truncation to user?" as a concern for the 'loss of information' arising from the
-effectively left-truncated strings. We reject this question's premise that there
-ever is such a case of unintentional loss of information, considering the two
-cases of hardware-aware integers and otherwise:
-
-So far we have played around with examples of bytes in ``range(-128, 256)``,
-the union of the signed and unsigned ranges, with respect to which the virtues
-of formatting ``x`` and ``x - 256`` as the same are clearly established. In the
-hardware-aware contexts that one expects to find ``z``, any integers corresponding
-to bytes that lie outside that range are likely a programming error. For example
-if a library sets a pixel brightness integer to be 257, and prints out ``'0x01'``
-instead of ``'0x101'`` via ``f"{x:z#.2x}"``, that's not our problem or doing; string
-formatting shouldn't raise an exception, or even a ``SyntaxWarning`` as an invalid
-escape sequence ``"\y"`` would, because ``ValueError: bytes must be in range(0, 256)``
+The remaining question is "is there no chance to communicate this truncation to
+the user?" as a concern for the 'loss of information' arising from the effectively
+left-truncated strings. We reject this question's premise that there ever is such
+a case of unintentional loss of information, by considering the two cases of
+hardware-aware integers and otherwise:
+
+With respect to hardware-aware integers we have so far played around with examples
+of integers in ``range(-128, 256)``, the union of the signed and unsigned ranges
+for bytes. The virtues of formatting ``x`` and ``x - 256`` as the same are clearly
+established. In these contexts that one expects to find ``z``, any erroneous integers
+corresponding to bytes that lie outside that range are likely a programming error.
+For example if a library sets a pixel brightness integer to be 257, and prints out
+``'0x01'`` instead of ``'0x101'`` via ``f"{x:z#.2x}"``, that's not our problem or
+doing; string formatting shouldn't raise an exception, or even a ``SyntaxWarning``
+as an invalid escape sequence ``"\y"`` would, because ``ValueError: bytes must be in range(0, 256)``
 will be raised by ``bytes`` when trying to serialize that integer via ``bytes([257])``;
 let the appropriate 'layer' of code raise the exception, as that is more indicative
 of a defect in the library, not our string formatting.
 
-In the case of non-hardware aware integers one would have to intentionally opt to
+In the case of non-hardware aware integers, one would have to intentionally opt to
 use ``z``, in which modular arithmetic is the chosen desired effect. It is for
 this reason also that we shall not raise a ``SyntaxWarning`` or ``ValueError``
 for integers lying outside of ``range(-base ** precision / 2, base ** precision)``.
 
-..
-  XXX Give a good example of non-hardware aware use of modular arithmetic
-  formatting like Minecraft buried treasure always being at 8,8 within a chunk.
-
 Thus we have defended the lossy behavior of ``z`` implemented as modulo-precision,
 and we have exhausted all reasonable use cases of lossless behavior.
 
 A final compromise to consider and reject is implementing ``z`` not as a flag
-*dependent* on ``.``, but as a flag that can be *combined* with ``.``.
+*contingent* on ``.``, but as a flag that can be *combined* with ``.``.
 Specifically: ``z`` without ``.`` would turn on two's complement mode to render
 the minimal width representation of the formatted integer, ``.`` without ``z``
 would implement precision as already explained, a minimum number of digits in the
@@ -564,13 +560,6 @@ This document is placed in the public domain or under the
 CC0-1.0-Universal license, whichever is more permissive.
 
 
-TODO AND REMOVE BEFORE MERGE
-============================
-
-* Give a good example of non-hardware aware use of modular arithmetic formatting,
-  my brain has gone blank...
-
-
 Footnotes
 =========