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 <1393683633.17.0.424512431546.issue11558@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
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: <1393683633.17.0.424512431546.issue11558@psf.upfronthosting.co.za>
2014-03-01 14:20:33r.david.murraylinkissue11558 messages
2014-03-01 14:20:32r.david.murraycreate