[Python-checkins] cpython (merge 3.3 -> default): Merge: Add notes to whatsnew porting for visible changes in email compatibility
r.david.murray
python-checkins at python.org
Sun Sep 30 07:29:02 CEST 2012
http://hg.python.org/cpython/rev/ce2a1553ad5c
changeset: 79295:ce2a1553ad5c
parent: 79293:cf50a352fe22
parent: 79294:74be0e7d8d58
user: R David Murray <rdmurray at bitdance.com>
date: Sun Sep 30 01:28:53 2012 -0400
summary:
Merge: Add notes to whatsnew porting for visible changes in email compatibility mode.
files:
Doc/whatsnew/3.3.rst | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst
--- a/Doc/whatsnew/3.3.rst
+++ b/Doc/whatsnew/3.3.rst
@@ -2102,6 +2102,22 @@
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
--------------
--
Repository URL: http://hg.python.org/cpython
More information about the Python-checkins
mailing list