[Python-Dev] Patch making the current email package (mostly) support bytes
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
> 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