R. David Murray <rdmur...@bitdance.com> added the comment:
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.
----------
assignee: -> docs@python
components: +Documentation -email
nosy: +docs@python
stage: -> needs patch
type: -> behavior
versions: +Python 3.3 -Python 3.1
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15115>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
