[Python-Dev] Patch making the current email package (mostly) support bytes (original) (raw)

R. David Murray rdmurray at bitdance.com
Thu Oct 7 19:46:02 CEST 2010

On Thu, 07 Oct 2010 16:03:18 -0000, lutz at rmi.net wrote:

I'm forwarding a link to the code of these clients to David by private email in case they might be useful as a test case (O'Reilly has already posted them ahead of the book, but they may be a bit too heavy for use in formal testing).

Thanks very much. I will take a look, and expect they will be helpful.

The email package is obviously less than ideal today, and there are many other clients for it besides my own, of course. But making it backward incompatible at this point is likely to be seen as a big negative to newcomers evaluating 3.X viability. And as I tried to make clear in June, this list should carefully weigh the PR cost of pulling the rug out from under those brave souls who have already taken the time to accommodate the 3.X world you've mandated.

Well, as I have said before the plan is to provide backward compatibility in email6, so that you only need to change your code if you want to take advantage of improved or new functionality. If this turns out not to be possible for some reason, then we aren't going to suddenly stop supporting email5. That's not the Python Way :) (Example: we added ArgParse post-3.0, and lots of people wanted to deprecate OptParse, but we aren't planning on removing OptParse.)

Do you see any issues with the patch I'm proposing? My goal is to make things work that didn't work before, but nothing that worked before should stop working, if I do my job right.

The one potentially backward-incompatible change that I'm consciously considering (that is, any other backward incompatibilities will be bugs) is having DecodedGenerator fully decode headers and emit full unicode, rather than the ASCII-only unicode that Generator emits. Can you think of any problem that that would cause? A quick grep indicates your own code does not use that generator (possibly because currently it does not do that decoding). I could, of course, only enable header decoding if a flag is passed requesting it, and as I write this I realize that that is indeed what I should do. Even though I haven't been able to think of a case where DecodedGenerator producing non-ASCII unicode would be an issue, that doesn't mean there isn't one :)

To put that more strongly, the Python user base is much larger than this list's readership. If I'm using 3.1 email, so are many others. People will accept the 3.X world you make up to a point, but it's impossible to code to a moving target, much less base a product on it. At some point, they'll simply stop trying to keep up; in fact, some already have.

Fixes are a Good Thing, of course, and this particular change's scope remains to be seen; but to channel most of the users I meet out there in the real world today: Enough with the 3.X changes already, eh?

Now that Python3 is out, the backward compatibility policy for it is the same as it always was for Python2. Only the transition from 2 to 3 broke backward compatibility in a significant way. From here on, we are as conservative as we always have been at making backward incompatible changes (that is, we don't do it intentionally without a good reason and a deprecation cycle, and if we do it unintentionally it is a regression and treated as such).

-- R. David Murray www.bitdance.com

More information about the Python-Dev mailing list