Author r.david.murray
Recipients barry, mkaiser, r.david.murray
Date 2019-12-17.20:10:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1576613429.53.0.509320276884.issue39071@roundup.psfhosted.org>
In-reply-to
Content
The problem is that you are starting with different inputs.  unicode strings and bytes are different things, and so parsing them can produce different results.  The fact of that matter is that email messages are defined to be bytes, so parsing a unicode string pretending it is an email message is just asking for errors anyway.  The string parsing methods are really only provided for backward compatibility and historical reasons.

I thought this was clear from the existing documentation, but clearly it isn't :)  I'll review a suggested doc change, but the thing to explain is not that parse and parsebytes might produce different results, but that parsing email from strings is not a good idea and will likely produce unexpected results for anything except the simplest non-mime messages.

Note: the reason you got different checksums might have had to do with line ends, depending on how you calculated the checksums.  You should also consider using get_content and not get_payload.  get_payload has a weird legacy API that doesn't always do what you think it will, and that might be another source of checksum issues.  But really, parsing a unicode representation of a mime message is just likely to be buggy.
History
Date User Action Args
2019-12-17 20:10:29r.david.murraysetrecipients: + r.david.murray, barry, mkaiser
2019-12-17 20:10:29r.david.murraysetmessageid: <1576613429.53.0.509320276884.issue39071@roundup.psfhosted.org>
2019-12-17 20:10:29r.david.murraylinkissue39071 messages
2019-12-17 20:10:29r.david.murraycreate