From: R David Murray <rdmurray@bitdance.com>
Date: Tue, 19 Mar 2013 22:18:55 +0000 (-0400)
Subject: #1525919: Document MIMEText+set_payload encoding behavior.
X-Git-Tag: v3.2.4rc1~18^2
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=14b0124a29489e4b114b960e4f2ce0b55acbace6;p=python

#1525919: Document MIMEText+set_payload encoding behavior.
---

diff --git a/Doc/library/email.mime.rst b/Doc/library/email.mime.rst
index ae340f754c..2ce486820f 100644
--- a/Doc/library/email.mime.rst
+++ b/Doc/library/email.mime.rst
@@ -185,5 +185,15 @@ Here are the classes:
    minor type and defaults to :mimetype:`plain`.  *_charset* is the character
    set of the text and is passed as a parameter to the
    :class:`~email.mime.nonmultipart.MIMENonMultipart` constructor; it defaults
-   to ``us-ascii``.  No guessing or encoding is performed on the text data.
+   to ``us-ascii``.
+
+   Unless the ``_charset`` parameter is explicitly set to ``None``, the
+   MIMEText object created will have both a :mailheader:`Content-Type` header
+   with a ``charset`` parameter, and a :mailheader:`Content-Transfer-Endcoding`
+   header.  This means that a subsequent ``set_payload`` call will not result
+   in an encoded payload, even if a charset is passed in the ``set_payload``
+   command.  You can "reset" this behavior by deleting the
+   ``Content-Transfer-Encoding`` header, after which a ``set_payload`` call
+   will automatically encode the new payload (and add a new
+   :mailheader:`Content-Transfer-Encoding` header).