On 8/17/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > > 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.
In the specific case of HTTP, it certainly looks like the headers are represented on the wire as 7-bit ASCII and could be treated as bytes or strings by the header processing code it uses via rfc822.py. The actual body of the response should still be represented as bytes, which can be converted to strings by the application. I assume the current rfc822 handling means that MIME-encoded binary data in HTTP headers will come back as un-decoded strings. (But I'm not sure.) We don't have any tests in the httplib code for these cases. I would expect an application would prefer bytes for the un-decoded data or strings for the decoded data. Will email / rfc822 support this? Jeremy > > 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/jeremy%40alum.mit.edu > _______________________________________________ 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
