Hi, 2014/1/8 Mark Shannon <mark@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