[Python-3000] should rfc822 accept text io or binary io?
Jeremy Hylton
jeremy at alum.mit.edu
Tue Aug 7 17:52:05 CEST 2007
On 8/6/07, Fred Drake <fdrake at acm.org> wrote:
> On Aug 6, 2007, at 4:46 PM, skip at pobox.com wrote:
> > I thought rfc822 was going away. From the current module
> > documentation:
> > ...
> > Shouldn't rfc822 be gone altogether in Python 3?
>
> Yes. And the answers to Jeremy's questions about what sort of IO is
> appropriate for the email package should be left to the email-sig as
> well, I suspect. It's good that they've come up.
Hmmm. Should we being using the email package to parse HTTP headers?
RFC 2616 says that HTTP headers follow the "same generic format" as
RFC 822, but RFC 822 says headers are ASCII and RFC 2616 says headers
are arbitrary 8-bit values. You'd need to parse them differently.
I also wonder if it makes sense for httplib to depend on email. If it
is possible to write generic code, maybe it belongs in a common
library rather than in either email or httplib.
I meant my original email to ask a more general question: Does anyone
have some suggestions about how to design libraries that could deal
with bytes or strings? If an HTTP header value contains 8-bit binary
data, does the client application expect bytes or a string in some
encoding?
If you have a library that consumes file-like objects, how do you deal
with bytes vs. strings? Do you have two constructor options so that
the client can specify what kind of output the file-like object
products? Do you try to guess? Do you just write code assuming
strings and let it fail on a bad lower() call when it gets bytes?
Jeremy
>
>
> -Fred
>
> --
> Fred Drake <fdrake at acm.org>
>
>
>
>
More information about the Python-3000
mailing list