Shay Rojansky <r...@roji.org> added the comment: Sorry for disappearing, will be following this closer from now on.
Thanks for the responses (and the acknowledgement of a problem), David and Steffen. I understand the API design philosophy and the need to allow the production of invalid messages. The main problem point to me is what seems to be an inconsistency in the API: * When constructing a new message/part (i.e. in the constructor), management of the Content-Transfer-Encoding header and responsibility for doing base64 is done by the API. * But when using mutators (set_payload, set_charset), these become the responsibility of the caller, etc. So one aspect of the API is high-level, another low-level. I have no idea whether this was a planned thing in some way, and have a hard time estimating whether modifying the behavior (i.e. making set_payload/set_charset high-level like the constructor) would break apps that depend on the current low-level behavior... One thought though... Another part of the API already allows the user to indicate whether they want low or high level behavior: get_payload accepts the boolean decode flag. Would it not make sense to add a similar "encode" flag to set_payload? To be complete such a flag could also be added to the constructor. Apart from that, I guess a good doc patch would run along the lines of appending the following to set_charset's description: "Note that if a Content-Transfer-Encoding header is already present on the message, it is kept as is and no content transfer encoding is applied to the payload." This can ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11216> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
