>>>>> "FL" == Fredrik Lundh <fredrik@pythonware.com> writes:
FL> uhuh? and how exactly is this cooler than being able to do
FL> something like the following:
| import quopri, base64
| s = msg['from']
| parts = s.split('?')
| if parts[2].lower() == 'q':
| name = quopri.decodestring(parts[3])
| elif parts[2].lower() == 'b':
| name = base64.decodestring(parts[3])
FL> (going through the codec registry is slower, and imports more
FL> modules, but what's so cool with that?)
-------------------- snip snip --------------------
Python 2.2a0 (#4, Jun 6 2001, 13:03:36)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import quopri
>>> quopri.decodestring
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'quopri' module has no attribute 'decodestring'
>>> quopri.encodestring
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'quopri' module has no attribute 'encodestring'
-------------------- snip snip --------------------
Much cooler :)
Okay, okay, so we /could/ add encodestring/decodestring to quopri.py,
which isn't a bad idea. But it seems to me that the s.encode()
s.decode() API is nicely universal for any supported encoding.
but-what-do-i-know?-ly y'rs,
-Barry
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