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

[Victor Stinner]

Hi,

2014/1/8 Mark Shannon <mark at hotpy.org>:
> I'm opposed to adding methods to bytes for this, as I think it goes against
> the reason for the separation of str and bytes in the first place.

Well, sometimes practicability beats purity. Many developers
complained that Python 3 is too string. The motivation of the PEP is
to ease the transition from Python 2 to Python 3 and be able to write
the same code base for the two versions.

> bytes are just a sequence of 8bit clumps.
> The meaning of bytes depends on the encoding, but the proposed methods will
> have no encoding, but presume meaning.

Many protocols mix ASCII text with binary bytes. For example, an HTTP
server writes headers and then copy the content of a binary file (ex:
PNG picture, gzipped HTML page, whatever) *in the same stream*. There
are many similar examples. Just another one: PDF mixes ASCII text with
binary.

> What does b'%s' % 7 do?

See Examples of the PEP:

b'a%sc%s' % (b'b', 4) gives b'abc4'

(so b'%s' % 7 gives b'7')

> u'%s' % 7 calls 7 .__str__() which returns a (unicode) string.
> By implication b'%s' % 7 would call 7 .__str__() and ...

Why do you think do? bytes and str will have two separated
implementations, but might share some functions. CPython already has a
"stringlib" which shares as much code as possible between bytes and
str. For example, the "fastsearch" code is shared.

> And then what? Use the "default" encoding? ASCII?

Bytes have no encoding. There are just bytes :-)

IMO the typical usecase will by b'%s: %s' % (b'Header', binary_data)

> I am not opposed to adding new functionality, as long as it is not
> overloading the % operator or format() method.

Ok, I will record your oppisition in the PEP.

> binascii.format() perhaps?

Please read the Rationale of the PEP again, binascii.format() doesn't
solve the described use case.

Victor