[Email-SIG] email6 and Python 3.3

[R. David Murray]

On Mon, 28 Feb 2011 15:48:29 -0500, Barry Warsaw <barry at python.org> wrote:
> >unchanged) messages with unencoded 8bit characters in their headers.
> 
> Let me personally thank you profusely for taking this on and improving the
> email package so much in Python 3.2.  I know I'm not alone in saying this was
> a difficult task, and I really really appreciate all the work you've done.

Well, fortunately I've been enjoying it, and the increased recognition
is certainly one of the rewards, so thank you.

> I guess there are two ways to go about it: make email6 backward compatible
> (enough <wink>) with email 5.1 to be able to provide it under the same package
> namespace in Python 3.3.  I.e. no 'import email6' needed.
> 
> Or, have a completely different package hierarchy and do the whole
> deprecation dance.  I know *I* hope you don't choose the latter. :)

Yeah, I'd really like to avoid that if I can, and I not only
think I can, I think it makes sense to do it that way for reasons
in addition to backward compatibility: it makes the email package
much more easily extensible.

> If at all possible, I think a b/c wrapper would be great.  If not feasible,  is
> there some other definitive marker we can put in email6 Message instances that
> could be tested for in a LBYL way?  I wonder if Message should have an
> __version__ attribute or something?

So far I haven't thought of anything a wrapper can't handle, but
of course I won't know for sure until I write the beast.

Regardless, I think having some sort of introspection on the capabilities
of the Message object is a good idea, but let's hold off defining it
until later.  I'd like the design to be informed by the requirements of
handling externally-defined Message classes, as well as those provided
by the email package itself.  On the other hand, rather than getting
too complex, it may be sufficient/better to just define some sort of
"api version" that a class declares it provides.  I suppose it could be
an ABC, though personally I don't really like ABCs (but I'm not sure why).

> Everything else sounds great.

Thanks.

--David