Author r.david.murray
Recipients barry, michael.henry, r.david.murray, varun
Date 2014-03-01.14:20:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Thanks, Varun.  Your patch addresses an issue with the current API, but it doesn't address the problem raised in this issue.  The problem in this issue is what happens when the *payload* is a string, and you call attach (to attach a message object) on that message.

Your fix addresses what happens if you pass a string to attach itself.  This also results in an invalid message (it ends up with a payload that contains a list consisting of a single string).  Thinking about changing this raises some interesting questions, though.  For one, the problem isn't that the argument to attach was a string, but that it was not an object that generator knows how to handle (that is, it wasn't a Message object).  For another, is it possible someone is using the email package in a weird context where attaching non-message objects is actually useful?  If so, and we disallow it, then we break someones code.

Since no one has reported calling attach with a non-message object as an actual bug, I'm inclined not to make this change.  Python is a "consenting adults" language, so unless there is a specific reason to disallow something, we generally allow it.

To work on a fix for the reported issue, you should start by turning the code in test_email_attach_to_string into a unit test.
Date User Action Args
2014-03-01 14:20:33r.david.murraysetrecipients: + r.david.murray, barry, michael.henry, varun
2014-03-01 14:20:33r.david.murraysetmessageid: <>
2014-03-01 14:20:33r.david.murraylinkissue11558 messages
2014-03-01 14:20:32r.david.murraycreate