[Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Eric V. Smith eric at trueblade.com
Sat Jan 11 02:53:09 CET 2014

On 1/10/2014 8:12 PM, Antoine Pitrou wrote:
> On Fri, 10 Jan 2014 16:23:53 -0800
> Ethan Furman <ethan at stoneleaf.us> wrote:
>> On 01/08/2014 02:42 PM, Antoine Pitrou wrote:
>>> With Victor's consent, I overhauled PEP 460 and made the feature set
>>> more restricted and consistent with the bytes/str separation.
>>  From the PEP:
>> =============
>>> Python 3 generally mandates that text be stored and manipulated as
>>>  unicode (i.e. str objects, not bytes). In some cases, though, it
>>>  makes sense to manipulate bytes objects directly. Typical usage is
>>>  binary network protocols, where you can want to interpolate and
>>>  assemble several bytes object (some of them literals, some of them
>>>  compute) to produce complete protocol messages. For example,
>>>  protocols such as HTTP or SIP have headers with ASCII names and
>>>  opaque "textual" values using a varying and/or sometimes ill-defined
>>>  encoding. Moreover, those headers can be followed by a binary
>>>  body... which can be chunked and decorated with ASCII headers and
>>>  trailers!
>> As it stands now, the PEP talks about ASCII, about how it makes sense
>> sometimes to work directly with bytes objects, and 
>> then refuses to allow % to embed ASCII text in the byte stream.
> Indeed I refuse for %-formatting to allow the mixing of bytes and str
> objects, in the same way that it is forbidden to concatenate "a" and
> b"b" together, or to write b"".join(["abc"]).

I think:
'a' + b'b'
is different from:
b'Content-Length: %d' % 42

The former we want to prevent, but I see nothing wrong with the latter.

So, I'm -1 on the PEP. It doesn't address the cases laid out in issue
3892. See for example http://bugs.python.org/issue3982#msg180432 .


More information about the Python-Dev mailing list