On 1/10/2014 8:12 PM, Antoine Pitrou wrote: > On Fri, 10 Jan 2014 16:23:53 -0800 > Ethan Furman <et...@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 . Eric. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
