> 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
_______________________________________________ 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
