[Email-SIG] email6 and Python 3.3
R. David Murray
rdmurray at bitdance.com
Mon Feb 28 22:32:35 CET 2011
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.
More information about the Email-SIG