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 barry, mardiros, r.david.murray
Date 2020-07-10.16:58:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1594400286.36.0.52159805349.issue41145@roundup.psfhosted.org>
In-reply-to
Content
The as_strings docs say:

"Flattening the message may trigger changes to the Message if defaults need to be filled in to complete the transformation to a string (for example, MIME boundaries may be generated or modified)."

So, while this is indeed an API design bug, it isn't an actual bug in the code but rather is expected behavior, currently.  The historical reason for this is that the generator code looks at the entire message to make sure the boundary string is unique.  My long term plan for email included plans to rewrite the generator, and I was going to fix this issue at that point.  My life got too busy to be able to continue with email development work, though, so that never happened.

It has been *years* since I've looked at the code.  Thinking about it now, I'm wondering if it would be possible to use a GUID technique to generate the boundary and thus do exactly as you say: have make_alternative (and anything else that causes a boundary to be needed) pre-create the boundary.  That, I think, would mean we wouldn't need to change the generator, even though it would still be doing its (inefficient) check that the boundary was unique.  I'm not sure if it would work, though; it's been too long since I've looked at the relevant code.
History
Date User Action Args
2020-07-10 16:58:06r.david.murraysetrecipients: + r.david.murray, barry, mardiros
2020-07-10 16:58:06r.david.murraysetmessageid: <1594400286.36.0.52159805349.issue41145@roundup.psfhosted.org>
2020-07-10 16:58:06r.david.murraylinkissue41145 messages
2020-07-10 16:58:06r.david.murraycreate