> Ideally, the package would be well suited not only for wire-to-wire > and all-internal uses, but also related domains like HTTP and other > RFC 2822-like contexts.
But that's exactly why the internal representation should be bytes, not strings. HTTP's use of MIME, for instance, uses "binary" quite a lot. > Internally though, I feel fairly strongly that an email > message should be represented as strings, though sometimes (certainly > for idempotency) you still need to carry around the charset (i.e. > encoding). What if you've got a PNG as one of the multipart components? With a Content-Transfer-Encoding of "binary"? There's no way to represent that as a string. I wonder if we're misunderstanding each other here. The "mail message" itself is essentially a binary data structure, not a sequence of strings, though many of its fields consist of carefully specified string values. Is that what you're saying? That when decoding the message, the fields which are string-valued should be kept as strings in the internal Python representation of the message? Bill _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
