So, designing a new interface is one thing. Making the current
interface usable in py3k is another. I presume that the latter
is desirable?
I'm porting a small application that uses the email module to py3k.
I've run into two problems, one of which was already reported, the other
of which was not:
http://bugs.python.org/issue4661
http://bugs.python.org/issue6302
(Then there's the whole string issues relating to email and unicode
organized under Issue1685453, but I'm going to ignore those for the
moment.)
I'd like to try fixing these, but there are design issues involved.
The fundamental one is, what format should 'message' be handling message
data in? 4661 addresses this obliquely, and we've talked about this
somewhat at the higher design level. But the question before me is,
how to fix feedparser, message, and decode_header so that I can actually
parse a message and display it correctly.
I need to be able to feed bytes to feedparser, that much is clear.
I've implemented a proof-of-concept fix that has feedparser handle all
its input as bytes, has message decode headers and values using the
ASCII codec if handled bytes, and has decode_header expect strings and
consistently return bytes.
With this fix in place my application works. But of course, the
email module tests do not pass, and I don't know what other use
cases I have broken.
My specific question, as posted in issue4661, is: is there any
use case for passing strings to feedparser that is not a design
error waiting to trap the programmer?
--David
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
