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 Arfrever, apollo13, barry, r.david.murray, vajrasky
Date 2013-10-30.19:16:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
msg.as_string should not be producing a CTE of 8bit.  I haven't looked at your patch so I don't know what you mean by having as_string produce 8bit data, but it can't be right :)

To clarify: as_string must produce valid unicode data, and therefore *cannot* have any 8bit data in it.  Unicode is not an 8bit channel (in SMTP terms) it is a 7bit channel (ie: restricted to ASCII).  The *decoded* version of the message can have non-ASCII in it, but as_string is producing an *encoded* version.  The CTE applies only to an encoded version.  

It gets a little confusing because in Python we are used to 'decoding' to unicode and 'encoding' to bytes, but in the email package we also sometimes 'encode' to ASCII but use unicode strings to store it.  If we didn't have to maintain backward compatibility it would probably be better to just drop as_string :)
Date User Action Args
2013-10-30 19:16:43r.david.murraysetrecipients: + r.david.murray, barry, Arfrever, apollo13, vajrasky
2013-10-30 19:16:43r.david.murraysetmessageid: <>
2013-10-30 19:16:43r.david.murraylinkissue19063 messages
2013-10-30 19:16:43r.david.murraycreate