[Python-Dev] PEP 332 revival in coordination with pep 349? [ Was:Re: release plan for 2.5 ?] (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Tue Feb 14 07:47:13 CET 2006

M.-A. Lemburg wrote:

We're talking about Py3k here: "abc" will be a Unicode string, so why restrict the conversion to 7 bits when you can have 8 bits without any conversion problems ?

YAGNI. If you have a need for byte string in source code, it will typically be "random" bytes, which can be nicely used through

bytes([0x73, 0x9f, 0x44, 0xd2, 0xfb, 0x49, 0xa3, 0x14, 0x8b, 0xee])

For larger blocks, people should use base64.string_to_bytes (which can become a synonym for base64.decodestring in Py3k).

If you have bytes that are meaningful text for some application (say, a wire protocol), it is typically ASCII-Text. No protocol I know of uses non-ASCII characters for protocol information.

Of course, you need a way to get .encode output as bytes somehow, both in 2.5, and in Py3k. I suggest writing

bytes(s.encode(encoding))

In 2.5, bytes() can be constructed from strings, and will do a conversion; in Py3k, .encode will already return a string, so this will be a no-op.

Regards, Martin

More information about the Python-Dev mailing list