[Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?] (original) (raw)

Jason Orendorff jason.orendorff at gmail.com
Thu Feb 16 21:00:42 CET 2006

On 2/15/06, Guido van Rossum <guido at python.org> wrote:

> Actually users trying to figure out Unicode would probably be better served > if bytes.encode() and text.decode() did not exist. [...] 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 agree, text.encode() and bytes.decode() are both swell. It's the other two that bother me.

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.

I prefer constructor flavor; the word "bytes" feels more concrete than "encode". But I worry about constructors being too overloaded.

text(b, enc) # decode text(mydict) # repr text(b) # uh... decode with default encoding?

-j -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060216/5138b8fa/attachment.htm

More information about the Python-Dev mailing list