Showing content from http://mail.python.org/pipermail/python-dev/attachments/20060215/224a3fe4/attachment.html below:
Instead of byte literals, how about a classmethod bytes.from_hex(), which works like this:<br>
<br>
# two equivalent things<br>
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')<br>
expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227, 131, 79, 229, 201, 46, 106])<br>
<br>
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.<br>
<br>
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:<br>
<br>
text.encode('utf-8') ==> bytes<br>
text.encode('rot13') ==> text<br>
bytes.encode('zip') ==> bytes<br>
bytes.encode('uu') ==> text (?)<br>
<br>
This state of affairs seems kind of crazy to me.<br>
<br>
Actually users trying to figure out Unicode would probably be better served if bytes.encode() and text.decode() did not exist.<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