homepage

The work I've been doing on email6 has reached a stage where I'm confident about the overall plan of the new code, and am ready for people to review it and make suggestions. The patch represents a working state of the code, but with several omissions that I will continue to work on while the rest of the code is reviewed. The major omissions are that address headers don't yet handle encoded words in their 'value' and related attributes, and that structured headers do not properly support unicode characters when the message is flattened. (The traditional email5 methods for handling unicode in structured headers still work fine, though). There are also edge-cases where the address parser does not do as well as email.utils.parseaddr (and other cases where it does better).
A goal of email6 is to be 100% backward compatible with the existing email5.1 API. If you find any deviations please let me know.
A new policy, email6_defaults, allows you to run the code with what are intended to be the defaults in Python 3.4. (Not specifying either email6_defaults or email5_defaults when creating a message will result in warning messages in cases where it would make a difference which policy was in force). The only difference between the two right now is that email6_defaults sets 'use_decoded' true, which means that the string value of header objects is the fully unicode version, not the ASCII-only version that comes from the source as is true with email5_defaults.
I've also released this version of the code as email-6.0.0a1 on pypi, so that it can be tested using 3.2 (you import it as 'email6').
I will separately attach here the README from the pypi package, which details the header features that are finished and the ones that still need work.
After review, I'd like to go ahead and check this in to default and continue the work from there. From this point until I start work on the message_factory all changes will be incremental. 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.
If, that is, the approach here is accepted :) The email-sig seems to like it.
Oh, yeah, and there's room for plenty of bike-shedding about certain attribute names &c.

As mentioned on python-dev, I'm planning to introduce the new header parsing/folding code as a provisional API in the spirit if not quite the letter of PEP 411. Issue 14731 is a pre-requisite for this issue, since this patch builds on to of that one.
This patch is almost entirely additions. At a later stage I can probably remove some of the older code, but the bulk of the backward compatibility stuff may have to remain around until Python4.

New changeset 0189b9d2d6bc by R David Murray in branch 'default':
#12586: add provisional email policy with new header parsing and folding.
http://hg.python.org/cpython/rev/0189b9d2d6bc 

New changeset 331cceee3b45 by R David Murray in branch 'default':
#12586: Expand What's New email entry with provisional policy features.
http://hg.python.org/cpython/rev/331cceee3b45 

New changeset 09e97829ed1e by R David Murray in branch 'default':
Add news entries for #14731 and #12586.
http://hg.python.org/cpython/rev/09e97829ed1e 

New changeset 2b6f183091b9 by R David Murray in branch 'default':
#12586: Fix a small oversight in the new email policy header setting code.
http://hg.python.org/cpython/rev/2b6f183091b9