>>>>> "M" == "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
M> James Y Knight wrote:
>> Nice and simple.
M> Albeit, too simple.
M> The above approach would basically remove the possibility to
M> easily create bytes() from literals in Py3k, since literals in
M> Py3k create Unicode objects, e.g. bytes("123") would not work
M> in Py3k.
No, it just rules out a builtin easy way to create bytes() from
literals.
But who needs to do that? codec writers and people implementing wire
protocols with bytes() that look like character strings but aren't.
OK, so this makes life hard on codec writers. But those implementing
wire protocols can use existing codecs, presumably 'ascii' will do 99%
of the time:
def make_wire_token (unicode_string, encoding='ascii'):
return bytes(unicode_string.encode(encoding))
Everybody else is just asking for trouble by using bytes() for
character strings. It would really be desirable to have "string" be a
Unicode literal in Py3k, and u"string" a syntax error.
M> To prevent [people from learning to write "bytes('string')" in
M> 2.x and expecting that to work in Py3k], you'd have to outrule
M> bytes() construction from strings altogether, which doesn't
M> look like a viable option either.
Why not? Either bytes() are the same as strings, in which case why
change the name? or they're not, in which case we ask people to jump
through the required hoops to create them. Maybe I'm missing some
huge use case, of course, but it looks to me like the use cases are
pretty specialized, and are likely to involve explicit coding anyway.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
_______________________________________________
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
