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 uau
Recipients arjennienhuis, benjamin.peterson, eric.smith, loewis, uau, vstinner
Date 2011-01-27.18:54:02
SpamBayes Score 1.110223e-16
Marked as misclassified No
Message-id <1296154442.72.0.0972227378927.issue3982@psf.upfronthosting.co.za>
In-reply-to
Content
This kind of formatting is needed quite often when working on network protocols or file formats, and I think the replies here fail to address important issues. In general you can't encode after formatting, as that doesn't work with binary data, and often it's not appropriate for the low-level routines doing the formatting to know what charset the data is in even if it is text (so it should be fed in already encoded as bytes). The replies from Martin v. Löwis seem to argue that you could use methods other than formatting; that would work almost as well as an argument to remove formatting support from text strings, and IMO cases where formatting is the best option are common.

Here's an example (based on real use but simplified):

template = b"""
stuff here
header1: {}
header2: {}
more stuff
"""

def lowlevel_send(s, b1, b2):  # s socket, b1 and b2 bytes
    s.send(template.format(b1, b2))

To clarify the requirements a bit, the issue is not so much about having a .format method on byte string objects (that's just the most natural-looking way of solving it); the core requirement is to have a formatting operator that can take byte strings as *arguments* and produce byte string *output* where the arguments can be placed unchanged.
History
Date User Action Args
2011-01-27 18:54:02uausetrecipients: + uau, loewis, vstinner, eric.smith, benjamin.peterson, arjennienhuis
2011-01-27 18:54:02uausetmessageid: <1296154442.72.0.0972227378927.issue3982@psf.upfronthosting.co.za>
2011-01-27 18:54:02uaulinkissue3982 messages
2011-01-27 18:54:02uaucreate