Re: [Python-Dev] Patch making the current email package (mostly) support bytes
Stephen J. Turnbull wrote (giving me an opening to jump in here):
R. David Murray writes:
In other words, my proposed patch only makes email5 1/8 to 1/4 broken, instead of half broken as it is now. But not un-broken enough for Mailman, it sounds like.
IMO, not in the long run. But realistically, in the applications I know of, most desired traffic is conformant, and since there aren't any Python 3 email apps yet, this isn't even a regression. :-/
Well, yes there are, and yes it is. As I pointed out in a thread on this list back in June, there are multiple large Python 3 email "apps" in the new Programming Python, a book which is about to be released, and which will be read by at least tens of thousands of people, many of whom will be evaluating the stability of Python 3. These apps include both a simple webmail site, as well as a more sophisticated 5k-line tkinter email client -- one which I've been using for all my personal and business email over the last 6 months, and which works well with the email package as it is in 3.1 (albeit with a bit of workaround code). This includes support for Unicode, MIME, headers, attachments, and the lot. 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). 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. 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? --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
On Thu, 07 Oct 2010 16:03:18 -0000, lutz@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
lutz@rmi.net writes:
To put that more strongly, the Python user base is much larger than this list's readership.
Agreed. Nevertheless, this is the channel (not "channel") that the developers listen on, and substantial effort is made to let Python users know that. I think they do know it, too.
If I'm using 3.1 email, so are many others.
That's not obvious. 3.1 email is unusable for several applications. In fact, for human factors reasons (humans are very likely to communicate with other humans who use the same encodings, and to accept occasional glitches they must deal with manually), MUAs are likely to port relatively easily as "good enough" software. But I doubt very much that folks writing MTAs or spam filters that must run unattended, often in long-lived, very active processes, are producing production versions using Python 3 email yet.
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.
"Impossible is nothing." It's a decision that each individual developer makes for herself. I haven't heard Mailman devs complain about the impossibility of dealing with the proposed changes, for example. Quite the reverse, in fact.
At some point, they'll simply stop trying to keep up; in fact, some already have.
Predictable and predicted. Where's the balance? I don't know, but "channeling" the users is not a lot of help. There are three worthy goals here: 1. Taking advantage of improvements in to-be-released Pythons. 2. Not changing one's own working code. 3. Not participating in python-dev/email-sig. Take any two; one can't have all three. More specifically, it's interesting that most of the users you talk to care enough to actually say they don't want more incompatible changes. But what are we supposed to take from that? Some fixes have to be incompatible; do the users want the fix or the compatibility? You waffle (as a good representative often must):
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?
But that's also a decision each developer *can* make for himself. Python does not withdraw products, or even withdraw support, just because the core developers release something they consider better. If having 1 *and* 2 is so important to particular users, but they come into conflict because of proposed changes in Python, then they're going to have to give up 3, come here, and articulate their needs. As you are doing -- but to have real influence, you're going to have to do the review of David's patch that he requests. I really don't see how the process can work any other way.
participants (3)
-
lutz＠rmi.net -
R. David Murray -
Stephen J. Turnbull