Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit ea1badb

Browse files
committed
#1440472: Explain that email parser/generator isn't *quite* "idempotent"
1 parent 4d377d9 commit ea1badb

1 file changed

Lines changed: 11 additions & 1 deletion

File tree

Doc/library/email.generator.rst

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,8 @@ yourself. However the bundled generator knows how to generate most email in a
1717
standards-compliant way, should handle MIME and non-MIME email messages just
1818
fine, and is designed so that the transformation from flat text, to a message
1919
structure via the :class:`~email.parser.Parser` class, and back to flat text,
20-
is idempotent (the input is identical to the output). On the other hand, using
20+
is idempotent (the input is identical to the output) [#]_. On the other hand,
21+
using
2122
the Generator on a :class:`~email.message.Message` constructed by program may
2223
result in changes to the :class:`~email.message.Message` object as defaults are
2324
filled in.
@@ -204,3 +205,12 @@ representing the part.
204205
The default value for *fmt* is ``None``, meaning ::
205206

206207
[Non-text (%(type)s) part of message omitted, filename %(filename)s]
208+
209+
210+
.. rubric:: Footnotes
211+
212+
.. [#] This statement assumes that you use the appropriate setting for the
213+
``unixfrom`` argument, and that you set maxheaderlen=0 (which will
214+
preserve whatever the input line lengths were). It is also not strictly
215+
true, since in many cases runs of whitespace in headers are collapsed
216+
into single blanks. The latter is a bug that will eventually be fixed.

0 commit comments

Comments
 (0)