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 <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com