R. David Murray added the comment: 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. ---------- components: +email nosy: +barry _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11558> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
