2.3 currently has the following behaviour:

>>> 'hello world'.encode('quopri')
'hello=20world'
>>> 'hello world'.encode('quopri').decode('quopri')
'hello world'
>>> u'hello world'.encode('quopri')
'=00h=00e=00l=00l=00o=00=20=00w=00o=00r=00l=00d'
>>> u'hello world'.encode('quopri').decode('quopri')
'\x00h\x00e\x00l\x00l\x00o\x00 \x00w\x00o\x00r\x00l\x00d'

I think the quoted printable encoding method should
either implicitly convert Unicode strings to US-ASCII,
or raise an exception.

Logged In: YES 
user_id=38388

A change to StringIO/cStringIO would be needed to change this,
unless you want to add a special case to the codec testing
for Unicode.

I don't have time to look into this, sorry.

This is the same issue you can see with
cStringIO.StringIO(u"abc").getvalue().  This behavior will not be
changed, as per #1730114.

Marc-Andre: would it be okay to add an explicit str() call in the
StringIO calls in quopri_codec and uu_codec, so that non-ASCII unicode
strings give an error on decode(), as binascii.b2a_qp() does?

Georg: Yes, sure.

Okay, changed in rev. 57925. Closing this as fixed.