> 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. Regards, Martin
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