This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients barry, cancel, docs@python, r.david.murray
Date 2012-06-20.13:51:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340200280.75.0.169898607846.issue15115@psf.upfronthosting.co.za>
In-reply-to
Content
First of all, I presume you are running this in python2.7, since it doesn't work in python3.  In Python3 MIMEText takes a string as input, not a bytes object, unless you pass it a _charset parameter.  If you do that, the encoding is done when the object is created, and the explicit call to encodings that you do fails.  If, on the other hand, you pass in a string, the explicit call to encodings fails.

In 2.7, the encoder call does not fail, but as you report this results in an extra header.  This is because MIMEText sets a content type and CTE header using the default values when it is first created.

The explicit call to encoders is not needed  What you want to do in stead is to pass the charset and type when you make the MIMEText call:

  MIMEText('<xml>aaa</xml>', 'xml', 'utf-8')

This is the correct way to do it, and the portable way.  So, you get the right output by using the API the way it was designed.  

That leaves the question of whether or not we should add some documentation (such as: *never* call the functions from the encoders module directly :).

Note that I don't *like* that the current API is that calling set_charset does the body encode if and only if there are no existing headers, but that is the way it has always worked, and there are programs out there that depend on it.  

In theory we could fix the encoders functions to check for existing headers and do the right thing in that case, but it is not something that would rate very high on my priority list.  I'll happily look at a patch if someone wants to propose one, but since the right way to do this exists, I'm going to treat this issue as documentation-only.  

If someone wants to propose a patch for this, please open a new issue.
History
Date User Action Args
2012-06-20 13:51:20r.david.murraysetrecipients: + r.david.murray, barry, docs@python, cancel
2012-06-20 13:51:20r.david.murraysetmessageid: <1340200280.75.0.169898607846.issue15115@psf.upfronthosting.co.za>
2012-06-20 13:51:19r.david.murraylinkissue15115 messages
2012-06-20 13:51:17r.david.murraycreate