mirror of
https://github.com/python/cpython.git
synced 2025-09-26 10:19:53 +00:00
Add notes to whatsnew porting for visible changes in email compatibility mode.
This commit is contained in:
parent
6c57318c3a
commit
ea22685a04
1 changed files with 16 additions and 0 deletions
|
@ -2102,6 +2102,22 @@ Porting Python code
|
||||||
special case the standard import hooks so they are still supported even
|
special case the standard import hooks so they are still supported even
|
||||||
though they do not provide the non-standard ``iter_modules()`` method.
|
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
|
Porting C code
|
||||||
--------------
|
--------------
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue