R. David Murray <rdmur...@bitdance.com> added the comment: Well, the docs don't say that the headers will be removed or modified as needed, only added as needed ;/. And in fact the set_charset code does "if 'Content-Transfer-Encoding' not in self". set_payload also says it is the caller's responsibility to "maintain the payload's invariants". I'm not sure what that means, but I suspect it means making sure it is consistent with any existing Content-Transfer-Encoding header.
So it looks to me like this is (a) a doc bug and (b) an API bug(*). The latter can only be corrected in 3.3. I'm open to argument that this should be treated as a code bug, but that argument needs to include reasons why fixing it would not cause backward incompatibility problems. Although I assigned this to myself so I don't lose it, a proposed documentation patch would be welcome. (*) I say an API bug because my guess is that the API works the way it does on the theory that a program might be updating an existing Message object and should in that instance change only what it is directed to change (the payload content, and the charset attribute if specified), even if that would produce an invalid Message. The way the email package evolved this would make sense, but I think if we were (when we are) doing it over now a better API would be to maintain a valid Message object through the standard API and provide a "lower level" API for those programs needing to produce RFC-invalid messages for whatever reason. ---------- assignee: -> r.david.murray nosy: +r.david.murray stage: -> needs patch _______________________________________ 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
