Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Commit 29cb612

Browse filesBrowse files
committed
Re-phrase docs of set_content behavior for str payloads
The previous patch only illustrates this behavior with a very specific edge case, which IMO did not do a good job elucidating the present ambiguous documentation, if not worsening it by obscuring the true intention behind EOL canonicalization for messages of text/* types. This instead should address the more general case, abeit less concrete, which seems like a fair compromise, considering users who care about accurate representation of line endings will likely carefully study the documentation and be assured that this is an expected deviation from the legacy API, while those who do not are not befuddled by a footnote that seems to warn of something out of the blue. I do not know if this is true to the original author's intention, but it is my personal understanding of this implementation at least. :/ The case of bytes is also addressed briefly in a subsequent bullet point to assure the user that it is to be expected that all bytes are preserved as any arbitrary binary file ought to be. I wish I could state this more explicitly, but that seems rather hard without presumably restructuring this particular page, so I will leave it to the original author... :) Signed-off-by: Yizheng Meng <dev@rapidcow.org>
1 parent 982720c commit 29cb612
Copy full SHA for 29cb612

File tree

Expand file treeCollapse file tree

1 file changed

+7
-8
lines changed
Filter options
Expand file treeCollapse file tree

1 file changed

+7
-8
lines changed

‎Doc/library/email.contentmanager.rst

Copy file name to clipboardExpand all lines: Doc/library/email.contentmanager.rst
+7-8Lines changed: 7 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -156,7 +156,13 @@ Currently the email package provides only one concrete content manager,
156156
:exc:`ValueError`.
157157

158158
* For ``str`` objects, if *cte* is not set use heuristics to
159-
determine the most compact encoding.
159+
determine the most compact encoding. Prior to encoding,
160+
:meth:`str.splitlines` is used to normalize all line boundaries,
161+
ensuring that each line of the payload is terminated by the
162+
current policy's :data:`~email.policy.Policy.linesep` property
163+
(even if the original string did not end with one).
164+
* For ``bytes`` objects, *cte* is taken to be base64 if not set,
165+
and the aforementioned newline translation is not performed.
160166
* For :class:`~email.message.EmailMessage`, per :rfc:`2046`, raise
161167
an error if a *cte* of ``quoted-printable`` or ``base64`` is
162168
requested for *subtype* ``rfc822``, and for any *cte* other than
@@ -191,13 +197,6 @@ Currently the email package provides only one concrete content manager,
191197
(distinguished from strings by having a ``name`` attribute), add the
192198
headers to *msg*.
193199

194-
Note that this method will append a newline character to the end of strings,
195-
if it wasn't passed already. For example, the following are equivalent ::
196-
197-
msg = EmailMessage()
198-
msg.set_content("hello")
199-
msg.set_content("hello\n")
200-
201200

202201
.. rubric:: Footnotes
203202

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.