From: R David Murray Date: Sun, 30 Sep 2012 05:27:24 +0000 (-0400) Subject: Add notes to whatsnew porting for visible changes in email compatibility mode. X-Git-Tag: v3.4.0a1~2458^2 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=ea22685a042dd8033fc9217af9d7c2fb793a649a;p=python Add notes to whatsnew porting for visible changes in email compatibility mode. --- diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst index 1943a06140..4e62595445 100644 --- a/Doc/whatsnew/3.3.rst +++ b/Doc/whatsnew/3.3.rst @@ -2102,6 +2102,22 @@ Porting Python code special case the standard import hooks so they are still supported even though they do not provide the non-standard ``iter_modules()`` method. +* A longstanding RFC-compliance bug (:issue:`1079`) in the parsing done by + :func:`email.header.decode_header` has been fixed. Code that uses the + standard idiom to convert encoded headers into unicode + (``str(make_header(decode_header(h))``) will see no change, but code that + looks at the individual tuples returned by decode_header will see that + whitespace that precedes or follows ``ASCII`` sections is now included in the + ``ASCII`` section. Code that builds headers using ``make_header`` should + also continue to work without change, since ``make_header`` continues to add + whitespace between ``ASCII`` and non-``ASCII`` sections if it is not already + present in the input strings. + +* :func:`email.utils.formataddr` now does the correct content transfer + encoding when passed non-``ASCII`` display names. Any code that depended on + the previous buggy behavior that preserved the non-``ASCII`` unicode in the + formatted output string will need to be changed. + Porting C code --------------