mirror of
https://github.com/python/cpython.git
synced 2025-09-26 18:29:57 +00:00
#1440472: Explain that email parser/generator isn't *quite* "idempotent"
This commit is contained in:
parent
4d377d98a1
commit
ea1badbfef
1 changed files with 11 additions and 1 deletions
|
@ -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
|
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
|
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,
|
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
|
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
|
result in changes to the :class:`~email.message.Message` object as defaults are
|
||||||
filled in.
|
filled in.
|
||||||
|
@ -204,3 +205,12 @@ representing the part.
|
||||||
The default value for *fmt* is ``None``, meaning ::
|
The default value for *fmt* is ``None``, meaning ::
|
||||||
|
|
||||||
[Non-text (%(type)s) part of message omitted, filename %(filename)s]
|
[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.
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue