Showing content from http://mail.python.org/pipermail/python-dev/attachments/20060216/5138b8fa/attachment.htm below:
On 2/15/06, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Actually users trying to figure out Unicode would probably be better served<br>> if bytes.encode() and text.decode() did not exist.<br>[...]<br>It would be better if the signature of text.encode() always returned a
<br>bytes object. But why deny the bytes object a decode() method if text<br>objects have an encode() method?</blockquote><div><br>
I agree, text.encode() and bytes.decode() are both swell. It's the
other two that bother me.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'd say there are two "symmetric" API flavors possible (t and b are<br>
text and bytes objects, respectively, where text is a string type,<br>either str or unicode; enc is an encoding name):<br><br>- b.decode(enc) -> t; t.encode(enc) -> b<br>- b = bytes(t, enc); t = text(b, enc)<br><br>
I'm not sure why one flavor would be preferred over the other,<br>although having both would probably be a mistake.<br></blockquote></div><br>
I prefer constructor flavor; the word "bytes" feels more concrete than
"encode". But I worry about constructors being too overloaded.<br>
<br>
>>> text(b, enc) # decode<br>
>>> text(mydict) # repr<br>
>>> text(b) # uh... decode with default encoding?<br>
<br>
-j<br>
<br>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4