This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Arfrever, Christian H, barry, belopolsky, eric.smith, gotgenes, ncoghlan, vstinner
Date 2017-05-01.13:34:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1493645652.6.0.624023689206.issue22385@psf.upfronthosting.co.za>
In-reply-to
Content
Copying the amended proposal from that python-ideas thread into here:

Start with a leading base format character (chosen to be orthogonal to the default format characters):

    "h": lowercase hex
    "H": uppercase hex
    "A": ASCII (using "." for unprintable & extended ASCII)

    format(b"xyz", "A") -> 'xyz'
    format(b"xyz", "h") -> '78797a'
    format(b"xyz", "H") -> '78797A'

Followed by a separator and "chunk size":

    format(b"xyz", "h 1") -> '78 79 7a'
    format(b"abcdwxyz", "h 4") -> '61626364 7778797a'

    format(b"xyz", "h,1") -> '78,79,7a'
    format(b"abcdwxyz", "h,4") -> '61626364,7778797a'

    format(b"xyz", "h:1") -> '78:79:7a'
    format(b"abcdwxyz", "h:4") -> '61626364:7778797a'

In the "h" and "H" cases, allow requesting a preceding "0x" on the chunks:

    format(b"xyz", "h#") -> '0x78797a'
    format(b"xyz", "h# 1") -> '0x78 0x79 0x7a'
    format(b"abcdwxyz", "h# 4") -> '0x61626364 0x7778797a'

In the thread, I suggested the section before the format character would use the standard string formatting rules (alignment, fill character, width, precision), but I now think that would be ambiguous and confusing, and would be better left as a post-processing step on the rendered text.
History
Date User Action Args
2017-05-01 13:34:12ncoghlansetrecipients: + ncoghlan, barry, belopolsky, vstinner, eric.smith, gotgenes, Arfrever, Christian H
2017-05-01 13:34:12ncoghlansetmessageid: <1493645652.6.0.624023689206.issue22385@psf.upfronthosting.co.za>
2017-05-01 13:34:12ncoghlanlinkissue22385 messages
2017-05-01 13:34:12ncoghlancreate