R. David Murray added the comment: I have to look at the implementation to remind myself how hard this would be to implement. The goal was to leave Header a legacy API...if you need that level of control, you use the old API. But I can see the functionality argument, and Header *is* a reasonable API for building such a custom header. It may be a while before I have time to take a look at it, though, so if anyone else wants to take a look, feel free :)
One problem is that while the parser does retain the cte of each encoded word, if the header is refolded for any reason the cte is (often? always? I don't remember) ignored because encoded words may be recombined during folding. And if you are creating the header inside a program, that header is going to get refolded on serialization, unless max_line_length is set to 0/None or the header fits on one line. So it's not obvious to me that this can work at all. What *could* work would be to have a policy setting to use something other than utf-8 for the CTE for encoding headers, but that would be a global setting (applying to all headers that are refolded during serialization). Basically, controlling the CTE of encoded words on an individual basis goes directly against the model used by the new Email API: in that model, the "model" of the email message is the *decoded* version of the message, and serialization is responsible for doing whatever CTE encoding is appropriate. The goal is to *hide* the details of the RFCs from the library user. So, if you want control at that level, you have to go back to the old API, which required you do understand what you were doing at the RFC level... ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21095> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
