On Apr 9, 2009, at 2:25 PM, Martin v. Löwis wrote: >> This is an interesting question, and something I'm struggling with >> for >> the email package for 3.x. It turns out to be pretty convenient to >> have >> both a bytes and a string API, both for input and output, but I think >> email really wants to be represented internally as bytes. Maybe. Or >> maybe just for content bodies and not headers, or maybe both. >> Anyway, >> aside from that decision, I haven't come up with an elegant way to >> allow >> /output/ in both bytes and strings (input is I think theoretically >> easier by sniffing the arguments). > > If you allow for content-transfer-encoding: 8bit, I think there is > just > no way to represent email as text. You have to accept conversion to, > say, base64 (or quoted-unreadable) when converting an email message to > text. Agreed. But applications will want to deal with some parts of the message as text on the boundaries. Internally, it should be all bytes (although even that is a pain to write ;). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 304 bytes Desc: This is a digitally signed message part URL: <http://mail.python.org/pipermail/python-dev/attachments/20090409/184e3c5f/attachment.pgp>
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