OK, so I've released the first iteration of the email6 package on pypi as email-6.0.0a1. After install you import it as email6. This will allow anyone curious and/or motivated to test it out under Python 3.2. I'm especially interested in anyone with a working program that uses email in 3.2: it should be completely backward compatible, and if it isn't I want to know ASAP.[*] I've also opened issue 12586 for review of the delta between default and the code that is in the release. I'd like to check the code in to default and continue to work on it from there. As I said in the issue comments: "When we originally planned out email6 we thought we'd be making a "compatibility break" with backward compatibility shims. As things have turned out the work is more a matter of incremental improvement of the API while maintaining the old API, and thus it seems reasonable to me to work on it directly in default rather than continue to work on it in a separate feature branch." Assuming, that is, that the general approach represented by *this* delta is accepted. What this delta adds to email is a conversion to handling all headers as full blown objects (as opposed to strings, tuples of strings, or Header objects, depending on context). The object type is a subclass of str, so the headers act like strings if you don't use their additional API. The basic additional API is that a 'source' attribute contains the text the generator read from the input source, and a 'value' attribute that contains the value with all the Content-Transfer-Encoding stuff undone so that you have a real unicode string. By changing a policy setting, you can have that value as the string value of the header. You can also assign a string with non-ASCII characters to a header, and the right thing will happen. (Well, eventually it will happen...right now it only works correctly for unstructured headers). Further, Date headers have a datetime attribute (and accept being set to a datetime), and address headers have attributes for accessing the individual addresses in the header. Other structured headers will eventually grow additional attributes as well. The general approach has been discussed with and approved by the email-sig, but all comments are welcome. I know there's room for bikeshedding on some aspects of the API; in some cases I've dome some "placeholder" stuff pending a more complete solution to certain design goals. I have a big project in the offing over the next couple months. QNX is still fully behind the funding for email6 development, but I probably won't be able to complete it until the fall. So I'd like to get this chunk (the biggest chunk of new code, considering the size of the parser) reviewed and checked in if possible. I'll keep working on the bits of functionality that aren't quite complete and the bugs that I know are there until my big project kicks off, but I wanted to release/post now so that there might be a chance of some review happening while I still have time to respond quickly to the feedback. -- R. David Murray http://www.bitdance.com [*] I believe that if you try to use an email6 Message object with the 3.2 mailbox module you will run in to some trouble, but I think it ought to be possible to make it work with the right magic :) PS: I don't have much experience writing parsers, so I'm expecting some critical comments about my parser design. It had to be a custom parser since otherwise I'd be blocked on waiting for some other software to get accepted into the stdlib, but it certainly wound up being a bigger chunk of code than I expected when I started writing it.