[Python-checkins] cpython (3.3): Add notes to whatsnew porting for visible changes in email compatibility mode.
r.david.murray
python-checkins at python.org
Sun Sep 30 07:29:01 CEST 2012
http://hg.python.org/cpython/rev/74be0e7d8d58
changeset: 79294:74be0e7d8d58
branch: 3.3
parent: 79292:1a08f4887cff
user: R David Murray <rdmurray at bitdance.com>
date: Sun Sep 30 01:27:24 2012 -0400
summary:
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