This PEP proposes to add minimal formatting operations to bytes andbytearray objects. The proposed additions are:
bytes%... andbytearray%... for percent-formatting,similar in syntax to percent-formatting onstr objects(accepting a single object, a tuple or a dict).bytes.format(...) andbytearray.format(...) for a formattingsimilar in syntax tostr.format() (accepting positional as well askeyword arguments).bytes.format_map(...) andbytearray.format_map(...) for anAPI similar tostr.format_map(...), with the same formattingsyntax and semantics asbytes.format() andbytearray.format().In Python 2,str%args andstr.format(args) allow the formattingand interpolation of bytestrings. This feature has commonly been usedfor the assembling of protocol messages when protocols are known to usea fixed encoding.
Python 3 generally mandates that text be stored and manipulated as unicode(i.e.str objects, notbytes). In some cases, though, it makessense to manipulatebytes objects directly. Typical usage is binarynetwork protocols, where you can want to interpolate and assemble severalbytes object (some of them literals, some of them compute) to producecomplete protocol messages. For example, protocols such as HTTP or SIPhave headers with ASCII names and opaque “textual” values using a varyingand/or sometimes ill-defined encoding. Moreover, those headers can befollowed by a binary body… which can be chunked and decorated with ASCIIheaders and trailers!
While there are reasonably efficient ways to accumulate binary data(such as using abytearray object, thebytes.join method orevenio.BytesIO), none of them leads to the kind of readable andintuitive code that is produced by a %-formatted or {}-formatted templateand a formatting operation.
In this proposal, percent-formatting forbytes andbytearraysupports the following features:
%s as well as%(name)s).%s will try to get aPy_buffer on the given value, and fallbackon calling__bytes__. The resulting binary data is inserted atthe given point in the string. This is expected to work with bytes,bytearray and memoryview objects (as well as a couple others suchas pathlib’s path objects).%c will accept an integer between 0 and 255, and insert a byte of thegiven value.Braces-formatting forbytes andbytearray supports the followingfeatures:
str.format() (explicitpositional lookup, auto-incremented positional lookup, keyword lookup,attribute lookup, etc.){},{0},{name}). This has the same semantics as%s for percent-formatting (see above).c modifier will accept an integer between 0 and 255, and insert abyte of the given value (same as%c above).All other features present in formatting ofstr objects (eitherthrough the percent operator or thestr.format() method) areunsupported. Those features imply treating the recipient of theoperator or method as text, which goes counter to the text / bytesseparation (for example, accepting%d as a format code would implythat the bytes object really is an ASCII-compatible text string).
Amongst those unsupported features are not only most type-specificformat codes, but also the various layout specifiers such as paddingor alignment. Besides,str objects are not acceptable as argumentsto the formatting operations, even when using e.g. the%s format code.
__format__ isn’t called.
It was proposed to create a new datatype specialized for “networkprogramming”. The authors of this PEP believe this is counter-productive.Python 3 already has several major types dedicated to manipulation ofbinary data:bytes,bytearray,memoryview,io.BytesIO.
Adding yet another type would make things more confusing for users, andinteroperability between libraries more painful (also potentiallysub-optimal, due to the necessary conversions).
Moreover, not one type would be needed, but two: one immutable type (toallow for hashing), and one mutable type (as efficient accumulation isoften necessary when working with network messages).
This PEP is made obsolete by theacceptanceofPEP 461, which introduces a more extended formatting language forbytes objects in conjunction with the modulo operator.
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-0460.rst
Last modified:2025-02-01 08:59:27 GMT