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

R. David Murray rdmurray at bitdance.com
Fri Oct 8 19:35:26 CEST 2010

On Fri, 08 Oct 2010 15:44:45 -0000, lutz at rmi.net wrote:

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 just landed the patch (though without the MIME encoding of unknown header bytes or the 'yes-I-really-want-the-escaped-bytes' flags that Stephen and I have been discussing. So it will be present in alpha3. I would greatly appreciate your testing it and making sure it doesn't break any of your code.

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

I don't perceive that lack of priority myself. Certainly I don't see a lack of priority on backward compatibility in the bug tracker, quite the reverse[*]. As I said in my public email, specific examples would be most helpful.

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.

Well, we can only react to the input we find out about. Developers do read blogs and such about what's going on in the wider community and bring that info back to python-dev, but as is inherent with projects structured as volunteer efforts, what we get is only what someone decides to put in time on. Specific suggestions on how to improve the feedback loop are always welcome; volunteer efforts to improve our fundamental procedures are just as or perhaps more valuable than volunteer code writing (though they probably involve even more politicing effort :).

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

Well, the Python community takes it as a principle to avoid thrashing. So if you see examples where we are failing in that goal, call us on it (with specifics).

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.

We do try to remain aware of that. When we fail, someone needs to let us know.

-- R. David Murray www.bitdance.com

[*] I'm currently aware of one exception to this, the nttplib module. It was pretty much unusable as it stood (I tried, as did Antoine; it had no unit tests so massive breakage is not that surprising), so we broke backward compatibility with 3.1 in order to fix that.

More information about the Python-Dev mailing list