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 ;).