[Python-Dev] Email6 status

[R. David Murray]

On Tue, 01 May 2012 10:55:03 -0400, Barry Warsaw <barry at python.org> wrote:
> On May 01, 2012, at 10:40 AM, R. David Murray wrote:
> >I guess it's time to talk about my plans for this one :)
> 
> Thanks for the update RDM.  I really wish I had more time to contribute to
> email6, but I'd still really like to see this land in 3.3 if possible.
> 
> I suspect you're just not going to get much practical feedback on email6 until
> it's available in Python's stdlib.  I don't know how many Python 3 email
> consuming applications there are out there.  The one I'm intimately familiar
> with <wink> still can't port to Python 3 because of its dependencies.

My thought exactly.

> >What I'd like to do is have the second patch introduce the new policies
> >as *provisional policies*.  That is, in the spirit but not the letter
> >of PEP 411, I'd like the new header API to be considered provisional
> >and subject to improvement in 3.4 based on what we learn by having it
> >actually out there in the field and getting tested.
> 
> That seems reasonable to me.  The documentation should be clear as to what's
> provisional and what's stable.  With that, and based on your level of
> confidence, I'd be in favor of getting email6 into Python 3.3.

OK, both patches are now up on the tracker.  The first patch, as
mentioned, does some internal refactoring that makes the policy
framework cleaner and adds hooks and a 'compat32' policy implementation
such that the current Python 3.2 behavior is preserved by default.

That's issue 14731: http://bugs.python.org/issue14731

The second patch adds a policy implementation (marked as provisional)
that adds the new header parsing and folding.  As of this patch only
'Date' type and 'Address' type headers are parsed as anything other than
Unstructured, but that's already worlds better than the compat32 policy.

That's issue 12586: http://bugs.python.org/issue12586

I would appreciate reviews of both patches, even cursory ones.  This
split up should make them as easy to review as such big patches can be:
the goal of 14731 is 100% backward compatibility, so a review can focus
on making sure that the tests match the Python 3.2 tests (with some
additions for bugs fixed).  125867 then adds a bunch of new code that
can be evaluated on its own merits.

Absent objection from patch reviewers, my plan is to apply these patches
before the next alpha (which is scheduled for May 26th, ie: next weekend).

--David