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

Skip to content

Commit b3ad106

Browse files
committed
merge #1440472: Explain that email parser/generator isn't *quite* "idempotent"
2 parents a008278 + ea1badb commit b3ad106

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.
@@ -223,3 +224,12 @@ representing the part.
223224
The default value for *fmt* is ``None``, meaning ::
224225

225226
[Non-text (%(type)s) part of message omitted, filename %(filename)s]
227+
228+
229+
.. rubric:: Footnotes
230+
231+
.. [#] This statement assumes that you use the appropriate setting for the
232+
``unixfrom`` argument, and that you set maxheaderlen=0 (which will
233+
preserve whatever the input line lengths were). It is also not strictly
234+
true, since in many cases runs of whitespace in headers are collapsed
235+
into single blanks. The latter is a bug that will eventually be fixed.

0 commit comments

Comments
 (0)