On 2/15/06, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> Instead of byte literals, how about a classmethod bytes.from_hex(), which
> works like this:
>
> # two equivalent things
> expected_md5_hash =
> bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
> expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227,
> 131, 79, 229, 201, 46, 106])
>
> It's just a nicety; the former fits my brain a little better. This would
> work fine both in 2.5 and in 3.0.
Yes, this looks nice.
> I thought about unicode.encode('hex'), but obviously it will continue to
> return a str in 2.x, not bytes. Also the pseudo-encodings ('hex', 'rot13',
> 'zip', 'uu', etc.) generally scare me. And now that bytes and text are
> going to be two very different types, they're even weirder than before.
> Consider:
>
> text.encode('utf-8') ==> bytes
> text.encode('rot13') ==> text
> bytes.encode('zip') ==> bytes
> bytes.encode('uu') ==> text (?)
>
> This state of affairs seems kind of crazy to me.
>
> Actually users trying to figure out Unicode would probably be better served
> if bytes.encode() and text.decode() did not exist.
Yeah, the pseudogeneralizations seem to be a mistake -- they are
almost universally frowned upon. I'll happily send their to their
grave in Py3k.
It would be better if the signature of text.encode() always returned a
bytes object. But why deny the bytes object a decode() method if text
objects have an encode() method?
I'd say there are two "symmetric" API flavors possible (t and b are
text and bytes objects, respectively, where text is a string type,
either str or unicode; enc is an encoding name):
- b.decode(enc) -> t; t.encode(enc) -> b
- b = bytes(t, enc); t = text(b, enc)
I'm not sure why one flavor would be preferred over the other,
although having both would probably be a mistake.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
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
