You know the old saying that “No news is good news”. Well, I’ve gotten no reviews of my proposal...so is that good or bad? I’m actually inclined to think that it is good, in this case. The one set of feedback I got was via this issue on github. The urllib3 folks at least seemed to think the ideas weren’t crazy. Out of that discussion came a decision to add a headers keyword argument to the set_content method, to make sure that even if the library doesn’t know about a particular MIME header, there’s an easy way to manually add it, just like it supports adding Content-Type parameters that the library doesn’t know about.
Beyond that I did check in with Barry Warsaw, the original maintainer of the email package, and the current maintainer of Mailman. While he did have some small concerns and hadn’t had time to write up a review, he didn’t see anything to criticize in the overall scheme. If anyone else on the email-sig list thought it was horrible, I’m pretty sure I’d have heard by now.
So, I’m expecting some bikeshedding down the road, but no major redesign.
That means I’ve gone ahead and started coding.
The first fruits of that work got posted as issue 18785 (closed) on Monday. The patch on that issue contains the beginnings of the documentation for the contentmanager module, and all of the documentation for a new MIMEMessage subclass to hold the new methods, plus the tests and implementation of the get_body() and iter_attachments() methods (as well as the trivial iter_parts() method). These methods are independent of the rest of the new API code.
As I note on the issue, I’m aware that there is an existing MIMEMessage class that is something completely different. However, unless the bikeshedders convince me otherwise, I’m planning on deprecating[1] the mime classes once set_content is no longer provisional, so since the name is the obvious choice, I’m not worried about the overlap myself.
The rest of it is all interrelated, so I’ll be submitting it as one big patchset when I’m done with it. I’m working in a copy of the code from the default branch that I’ve pushed to github. If you want to watch the work in progress you can follow the repository.
As always, comments are welcome. And, if anyone feels like contributing (for example by writing additional tests), pull requests are welcome too.
Footnotes
| [1] | Up until a week ago I would have said “but they won’t be removed before Python4”, but recently there has been some discussion on python-dev about our deprecation policy and Python4, so who knows, it might happen sooner. Though still not for several releases, I think. |