[issue19772] str serialization of Message object may mutate the payload and CTE.

R. David Murray report at bugs.python.org
Sat Feb 8 18:09:39 CET 2014


R. David Murray added the comment:

Vajrasky: thanks for your work on this, it helped me find a reasonable (if ugly) solution.  However, the 'if' statement in your patch that checks specifically for the combination of old and new cte of 8bit and base64 puzzles me.  The same problem occurs here if the CTE we end up with is quoted-printable, which will be the case, for example, for latin-1.  The logical way to think abut the problem here (we don't want to modify the message) would be "if the CTE changed, we need to restore it".  So why check specifically for 8bit and base64?  The straightforward translation of "if the CTE changed, we need to restore it" would have been: 'if self.orig_cte != cte'.

In my solution I preferred to leave the original object unchanged, and re-copy it to re-change the headers when needed.  This is ugly, but it is more future proof against the down-coding code someday changing other headers or other characteristics of the message.  And I needed to use deepcopy, because copy would just copy a pointer to the _headers list, and therefore the original headers list would still get modified.  The deepcopy isn't that costly here, though, because we know that it is only called on a message that is not a multipart, since the copies are triggered only from _handle_text.  It's still not pretty, but I think it is the best we can do without completely restructuring the way the generator does its work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19772>
_______________________________________


More information about the Python-bugs-list mailing list