This is the test case that fails in python 2.4.1:
from email.MIMEText import MIMEText
msg =
MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
msg.set_charset('utf-8')
msg.as_string()

And attached is a patch to correct it.

Your proposed patch doesn't seem to work in Python 2.5, or the trunk (i.e. it won't prevent an exception from occuring). Can you please revise it?

How about this version?

It was proposed to rewrite MIMEText in Python 3.1 (and 2.7?) to use 
unicode characters in the internals and reconvert to bytes to send it 
to a socket (or a file).

The patch by maxua works fine with 2.6 too and solves the problem.
I'd suggest it be applied to the 2.6 branch, even if email is rewriten
for 2.7/3.x.

What is the status of this?

It looks to me like MIMEText doesn't actually support unicode input.  .

One way to get the example to work is to do this:

 MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430'.encode('utf-8'), 'plain', 'utf-8')

The above call produces valid output from as_string:

'Content-Type: text/plain; charset="utf-8"\nMIME-Version:
1.0\nContent-Transfer-Encoding: base64\n\n0LrQuNGA0LjQu9C40YbQsA==\n'

How you'd get it to use 8bit, I have no idea.  Still, I'm inclined to
close this as invalid unless Barry tells me my analysis is wrong.

(CF: http://mg.pov.lt/blog/unicode-emails-in-python for a good example
of handling unicode using the email package, which I found after
figuring out the above.)

Clearly, the documentation of this could be better, but I suspect the
developers would rather spend their time fixing the email module in py3.
 A doc patch would certainly be accepted.  (Maybe someone could ask the
above blogger if we could borrow his example for the docs.)

After applying maxua's patch we do not get the unicode error but as david stated the support is not there. Here is the test.

>>> import email
>>> msg = email.MIMEText.MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
>>> msg.set_charset('utf8')
>>> msg.as_string()
'MIME-Version: 1.0\nContent-Transfer-Encoding: 8bit\nContent-Type: text/plain; charset="utf8"\n\n\xd0\xba\xd0\xb8\xd1\x80\xd0\xb8\xd0\xbb\xd0\xb8\xd1\x86\xd0\xb0'

This does not seems a viable general solution to the problem.

I guess, this issue should be closed and emphasis should be now on development of 'email 6.0'. By the way I mailed Marius, the author of the blog-post http://mg.pov.lt/blog/unicode-emails-in-python , if I can borrow his example for the doc-patch.

Hi David,
The attached patch for this issue:

+        if isinstance(payload, unicode):
+            payload = payload.encode(msg.get_charset().output_charset or 'us-ascii')

looks fine enough to me. Are you worried about the /or 'us-ascii'/ part of this patch? 

IMHO, the patch may prevent the straight forward Exception for which the issue was raised.

But on a larger scale, it is advisable to document MIMEText usage wth encoding as you mentioned.

I don't think either of the previous patches are correct.  I found a note in Issue1685453 that Barry would like for this to work, and after poking around in the code for a bit I think it can be done without breaking anything.

Attached is a patch that adds unicode support to MIMEText, including unit tests and docs updates.  Note that it is necessary to specify a charset if you have non-ASCII text in your unicode string, since the default charset is us-ascii.  The unit tests confirm this behavior.

Now the question is, is this a bug-fix or an enhancement?  I *think* it is safe to apply and backport, since I think the only behavior it changes is to make unicode input work, whereas before it would give a traceback.  But I've been wrong before :(

Ah, it's not 100% true that it doesn't change "working" behavior.  Before the patch, the first example in this ticket doesn't raise an error until the as_string call.  After this patch, the error is raised as soon as MIMEText is called without the charset parameter.  Since without the patch the code still fails eventually, I think this is an acceptable behavior change for a bug fix, but it does make me a little nervous :)

Updated patch with doc change to Message.set_charset attached.

Committed to 2.7 in r81658 and 2.6 in r81659.  I'm leaving this open for the moment because while py3 doesn't have this problem, the tests should still pass and they don't.

OK, py3k now passes all but one of the tests, and I've disabled that one pending email6 since fixing it would break backward compatibility within the 3.x series.  The fix is different, doing the encoding to output_charset just before calling base64mime.  This makes me think that quopri in py3k probably isn't working right, but that's a different issue.  I did not forward port the doc changes as they are inappropriate for py3k.

py3k patched in r81660, 3.1 in r81661.