Thanks for both your reply and work, David. I'm going to have to test my email clients under the 3.2 patch when it gels. It's good to hear that email5 API support remains a goal.
I don't mean to single out this change unfairly, of course. My real concern is not as much with the specific technical aspects of this proposal, as with the generally low priority that backward compatibility sometimes receives on this list. The bytecode file model change in 3.2 comes to mind as another example; sound as it may be, I'm not sure this list has any idea how many users, systems, or docs may be impacted by this. Though not always true, the work here does sometimes appear to be conducted in a vacuum. Ultimately, development in the open source world is driven by the very few with time to show up, rather than by the very many who depend on it. This can unfortunately lead to the perception of thrashing by end users. Some even come to see the net effect as not that much different from closed models. I have no solution to offer, except to underscore again that changes made here affect very many people who are too busy using Python to participate here. Especially given the still tentative state of 3.X, stability matters. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > -----Original Message----- > From: "R. David Murray" <rdmur...@bitdance.com> > To: l...@rmi.net > Subject: Re: [Python-Dev] Patch making the current email package (mostly) > support bytes > Date: Thu, 07 Oct 2010 13:46:02 -0400 > > On Thu, 07 Oct 2010 16:03:18 -0000, l...@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 > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
