.. index:: email6

Is No Review a Good Review?
===========================

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 :mailheader:`Content-Type`
parameters that the library doesn't know about.

.. _this: https://github.com/shazow/urllib3/issues/215#issuecomment-22417752

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` on Monday.  The
patch on that issue contains the beginnings of the documentation for the
:mod:`~email.contentmanager` module, and all of the documentation for a new
:class:`~email.message.MIMEMessage` subclass to hold the new methods, plus the
tests and implementation of the :meth:`~email.message.MIMEMessage.get_body` and
:meth:`~email.message.MIMEMessage.iter_attachments` methods (as well as the
trivial :meth:`~email.message.MIMEMessage.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 [#]_ the :mod:`~email.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_.

__ http://hg-git.github.io/
.. _repository: https://github.com/bitdancer/python-stdlib-email

As always, comments are welcome.  And, if anyone feels like contributing (for
example by writing additional tests), pull requests are welcome too.


.. rubric:: Footnotes

.. [#] 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.

       .. _discussion: http://code.activestate.com/lists/python-dev/123908/