On Mon, 28 Feb 2011 15:48:29 -0500, Barry Warsaw <ba...@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 _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com