From ea1badbfef340c63d4f821662c887e46ed62a6ec Mon Sep 17 00:00:00 2001 From: R David Murray Date: Tue, 15 May 2012 22:07:52 -0400 Subject: [PATCH] #1440472: Explain that email parser/generator isn't *quite* "idempotent" --- Doc/library/email.generator.rst | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/Doc/library/email.generator.rst b/Doc/library/email.generator.rst index 85b32fe7fe3..033dcf1c48b 100644 --- a/Doc/library/email.generator.rst +++ b/Doc/library/email.generator.rst @@ -17,7 +17,8 @@ yourself. However the bundled generator knows how to generate most email in a standards-compliant way, should handle MIME and non-MIME email messages just fine, and is designed so that the transformation from flat text, to a message structure via the :class:`~email.parser.Parser` class, and back to flat text, -is idempotent (the input is identical to the output). On the other hand, using +is idempotent (the input is identical to the output) [#]_. On the other hand, +using the Generator on a :class:`~email.message.Message` constructed by program may result in changes to the :class:`~email.message.Message` object as defaults are filled in. @@ -204,3 +205,12 @@ representing the part. The default value for *fmt* is ``None``, meaning :: [Non-text (%(type)s) part of message omitted, filename %(filename)s] + + +.. rubric:: Footnotes + +.. [#] This statement assumes that you use the appropriate setting for the + ``unixfrom`` argument, and that you set maxheaderlen=0 (which will + preserve whatever the input line lengths were). It is also not strictly + true, since in many cases runs of whitespace in headers are collapsed + into single blanks. The latter is a bug that will eventually be fixed.