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

James Y Knight foom at fuhm.net
Tue Feb 14 19:35:44 CET 2006

On Feb 14, 2006, at 11:47 AM, M.-A. Lemburg wrote:

The above approach would basically remove the possibility to easily create bytes() from literals in Py3k, since literals in Py3k create Unicode objects, e.g. bytes("123") would not work in Py3k.

That is true. And I think that is correct. There should be b"string"
syntax.

It's hard to imagine how you'd provide a decent upgrade path for bytes() if you introduce the above semantics in Py2.x.

People would start writing bytes("123") in Py2.x and expect it to also work in Py3k, which it wouldn't.

Agreed, it won't work.

To prevent this, you'd have to outrule bytes() construction from strings altogether, which doesn't look like a viable option either.

I don't think you have to do that, you just have to provide b"string".

I'd like to point out that the previous proposal had the same issue:

On Feb 13, 2006, at 8:11 PM, Guido van Rossum wrote:

On 2/13/06, James Y Knight <foom at fuhm.net> wrote:

In py3k, when the str object is eliminated, then what do you have? Perhaps - bytes("\x80"), you get an error, encoding is required. There is no such thing as "default encoding" anymore, as there's no str object. - bytes("\x80", encoding="latin-1"), you get a bytestring with a single byte of value 0x80.

Yes to both again.

James

More information about the Python-Dev mailing list