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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4