R. David Murray added the comment: Yes, the port from python2 to python3 of the email package was...suboptimal. (I wasn't a contributor when that happened, and the person who did it simply did not have time to do the needed rewrite...he had to settle for just making it more-or-less work.) The whole concept of using unicode as a 7bit data channel only is just...weird. But, we are now stuck with maintaining that API for backward compatibility reasons. To fix it, I rewrote significant parts of the email package, which is the new API. And even with that the internals are more than a bit hackish and I'd love to make further changes. I probably won't have time, though, since what we have now works and I'm not (currently) getting paid to work on it.
It also is...fraught with the danger of bugs...to talk about serializing an email message as a string, transforming it, and then trying to re-parse it as an email message. If your transformations are simple, it will probably work, but anything at all complex runs the risk of breaking the message. And having non-ascii bodies counts as non-trivial. The whole point of the Message model is to allow you to transform an email message and be able to produce an RFC valid serialization as the output after you are done. You do have to conditionalize your 2/3 code to use the bytes parser and generator if you are dealing with 8-bit messages. There's just no way around that. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25545> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
