[Python-Dev] email-6.0.0.a1

[R. David Murray]

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.