Skip to content

Commit b10ca0c

Browse files
gh-62978: Use Python 3 terms in the email package docs
Replace "Unicode string" with "string" and the unicode() built-in with str() in docstrings, comments and documentation of the email package. "byte string" is only replaced with "bytes" where other bytes-like objects are not accepted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 parent ef0affb commit b10ca0c

15 files changed

Lines changed: 44 additions & 44 deletions

Doc/library/email.compat32-message.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -96,7 +96,7 @@ Here are the methods of the :class:`Message` class:
9696
text = fp.getvalue()
9797

9898
If the message object contains binary data that is not encoded according
99-
to RFC standards, the non-compliant data will be replaced by unicode
99+
to RFC standards, the non-compliant data will be replaced by Unicode
100100
"unknown character" code points. (See also :meth:`.as_bytes` and
101101
:class:`~email.generator.BytesGenerator`.)
102102

Doc/library/email.contentmanager.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -96,9 +96,9 @@ Currently the email package provides only one concrete content manager,
9696

9797
This content manager provides only a minimum interface beyond that provided
9898
by :class:`~email.message.Message` itself: it deals only with text, raw
99-
byte strings, and :class:`~email.message.Message` objects. Nevertheless, it
99+
bytes, and :class:`~email.message.Message` objects. Nevertheless, it
100100
provides significant advantages compared to the base API: ``get_content`` on
101-
a text part will return a unicode string without the application needing to
101+
a text part will return a string without the application needing to
102102
manually decode it, ``set_content`` provides a rich set of options for
103103
controlling the headers added to a part and controlling the content transfer
104104
encoding, and it enables the use of the various ``add_`` methods, thereby
@@ -111,7 +111,7 @@ Currently the email package provides only one concrete content manager,
111111
parts), or a ``bytes`` object (for all other non-multipart types). Raise
112112
a :exc:`KeyError` if called on a ``multipart``. If the part is a
113113
``text`` part and *errors* is specified, use it as the error handler when
114-
decoding the payload to unicode. The default error handler is
114+
decoding the payload to a string. The default error handler is
115115
``replace``.
116116

117117
.. method:: set_content(msg, <'str'>, subtype="plain", charset='utf-8', \

Doc/library/email.examples.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ Here are a few examples of how to use the :mod:`email` package to read, write,
77
and send simple email messages, as well as more complex MIME messages.
88

99
First, let's see how to create and send a simple text message (both the
10-
text content and the addresses may contain unicode characters):
10+
text content and the addresses may contain Unicode characters):
1111

1212
.. literalinclude:: ../includes/email-simple.py
1313

Doc/library/email.header.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@ For example::
4949

5050
Notice here how we wanted the :mailheader:`Subject` field to contain a non-ASCII
5151
character? We did this by creating a :class:`Header` instance and passing in
52-
the character set that the byte string was encoded in. When the subsequent
52+
the character set to use when encoding it. When the subsequent
5353
:class:`~email.message.Message` instance was flattened, the :mailheader:`Subject`
5454
field was properly :rfc:`2047` encoded. MIME-aware mail readers would show this
5555
header using the embedded ISO-8859-1 character.
@@ -150,7 +150,7 @@ Here is the :class:`Header` class description:
150150
.. method:: __str__()
151151

152152
Returns an approximation of the :class:`Header` as a string, using an
153-
unlimited line length. All pieces are converted to unicode using the
153+
unlimited line length. All pieces are decoded using the
154154
specified encoding and joined together appropriately. Any pieces with a
155155
charset of ``'unknown-8bit'`` are decoded as ASCII using the ``'replace'``
156156
error handler.

Doc/library/email.headerregistry.rst

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,7 @@ headers.
4040

4141
*name* and *value* are passed to ``BaseHeader`` from the
4242
:attr:`~email.policy.EmailPolicy.header_factory` call. The string value of
43-
any header object is the *value* fully decoded to unicode.
43+
any header object is the *value* fully decoded to a string.
4444

4545
This base class defines the following read-only properties:
4646

@@ -95,10 +95,10 @@ headers.
9595
defects to this list. On return, the ``kwds`` dictionary *must* contain
9696
values for at least the keys ``decoded``, ``defects`` and ``parse_tree``.
9797
``decoded`` should be the string value for the header (that is, the header
98-
value fully decoded to unicode). ``parse_tree`` is set to the parse tree obtained
98+
value fully decoded to a string). ``parse_tree`` is set to the parse tree obtained
9999
from parsing the header. The parse method should assume that *string* may
100100
contain content-transfer-encoded parts, but should correctly handle all valid
101-
unicode characters as well so that it can parse un-encoded header values.
101+
Unicode characters as well so that it can parse un-encoded header values.
102102

103103
``BaseHeader``'s ``__new__`` then creates the header instance, and calls its
104104
``init`` method. The specialized class only needs to provide an ``init``
@@ -126,7 +126,7 @@ headers.
126126
mechanism for encoding non-ASCII text as ASCII characters within a header
127127
value. When a *value* containing encoded words is passed to the
128128
constructor, the ``UnstructuredHeader`` parser converts such encoded words
129-
into unicode, following the :rfc:`2047` rules for unstructured text. The
129+
into a string, following the :rfc:`2047` rules for unstructured text. The
130130
parser uses heuristics to attempt to decode certain non-compliant encoded
131131
words. Defects are registered in such cases, as well as defects for issues
132132
such as invalid characters within the encoded words or the non-encoded text.
@@ -203,8 +203,8 @@ headers.
203203
the list of addresses is "flattened" into a one dimensional list).
204204

205205
The ``decoded`` value of the header will have all encoded words decoded to
206-
unicode. :class:`~encodings.idna` encoded domain names are also decoded to
207-
unicode. The ``decoded`` value is set by :ref:`joining <meth-str-join>` the
206+
a string. :class:`~encodings.idna` encoded domain names are also decoded to
207+
a string. The ``decoded`` value is set by :ref:`joining <meth-str-join>` the
208208
:class:`str` value of the elements of the ``groups`` attribute with ``',
209209
'``.
210210

@@ -392,7 +392,7 @@ construct structured values to assign to specific headers.
392392
*domain*, in which case *username* and *domain* will be parsed from the
393393
*addr_spec*. An *addr_spec* must be a properly RFC quoted string; if it is
394394
not ``Address`` will raise an error. Unicode characters are allowed and
395-
will be property encoded when serialized. However, per the RFCs, unicode is
395+
will be property encoded when serialized. However, per the RFCs, Unicode is
396396
*not* allowed in the username portion of the address.
397397

398398
.. attribute:: display_name

Doc/library/email.policy.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -505,7 +505,7 @@ added matters. To illustrate::
505505
Otherwise the *name*, and the *value* with any CR or LF characters
506506
removed, are passed to the ``header_factory``, and the resulting
507507
header object is returned. Any surrogateescaped bytes get turned into
508-
the unicode unknown-character glyph.
508+
the Unicode unknown-character glyph.
509509

510510

511511
.. method:: fold(name, value)
@@ -600,10 +600,10 @@ the email package is changed from the Python 3.2 API in the following ways:
600600

601601
From the application view, this means that any header obtained through the
602602
:class:`~email.message.EmailMessage` is a header object with extra
603-
attributes, whose string value is the fully decoded unicode value of the
603+
attributes, whose string value is the fully decoded value of the
604604
header. Likewise, a header may be assigned a new value, or a new header
605-
created, using a unicode string, and the policy will take care of converting
606-
the unicode string into the correct RFC encoded form.
605+
created, using a string, and the policy will take care of converting
606+
the string into the correct RFC encoded form.
607607

608608
The header objects and their attributes are described in
609609
:mod:`~email.headerregistry`.

Doc/library/email.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -54,7 +54,7 @@ server.
5454

5555
The email package does its best to hide the details of the various governing
5656
RFCs from the application. Conceptually the application should be able to
57-
treat the email message as a structured tree of unicode text and binary
57+
treat the email message as a structured tree of Unicode text and binary
5858
attachments, without having to worry about how these are represented when
5959
serialized. In practice, however, it is often necessary to be aware of at
6060
least some of the rules governing MIME messages and their structure,
@@ -84,7 +84,7 @@ to advanced applications.
8484
Following those is a set of examples of using the fundamental parts of the APIs
8585
covered in the preceding sections.
8686

87-
The foregoing represent the modern (unicode friendly) API of the email package.
87+
The foregoing represent the modern (Unicode friendly) API of the email package.
8888
The remaining sections, starting with the :class:`~email.message.Message`
8989
class, cover the legacy :data:`~email.policy.compat32` API that deals much more
9090
directly with the details of how email messages are represented. The

Doc/library/email.utils.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -212,7 +212,7 @@ of the new API.
212212
When a header parameter is encoded in :rfc:`2231` format,
213213
:meth:`Message.get_param <email.message.Message.get_param>` may return a
214214
3-tuple containing the character set,
215-
language, and value. :func:`collapse_rfc2231_value` turns this into a unicode
215+
language, and value. :func:`collapse_rfc2231_value` turns this into a
216216
string. Optional *errors* is passed to the *errors* argument of :class:`str`'s
217217
:func:`~str.encode` method; it defaults to ``'replace'``. Optional
218218
*fallback_charset* specifies the character set to use if the one in the

Lib/email/_encoded_words.py

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -161,10 +161,10 @@ def decode(ew):
161161
This function expects exactly such a string (that is, it does not check the
162162
syntax and may raise errors if the string is not well formed), and returns
163163
the encoded_string decoded first from its Content Transfer Encoding and
164-
then from the resulting bytes into unicode using the specified charset. If
165-
the cte-decoded string does not successfully decode using the specified
164+
then from the resulting bytes into a string using the specified charset.
165+
If the cte-decoded string does not successfully decode using the specified
166166
character set, a defect is added to the defects list and the unknown octets
167-
are replaced by the unicode 'unknown' character \\uFDFF.
167+
are replaced by the Unicode 'unknown' character \\uFDFF.
168168
169169
The specified charset and language are returned. The default for language,
170170
which is rarely if ever encountered, is the empty string.
@@ -176,7 +176,7 @@ def decode(ew):
176176
# Recover the original bytes and do CTE decoding.
177177
bstring = cte_string.encode('ascii', 'surrogateescape')
178178
bstring, defects = _cte_decoders[cte](bstring)
179-
# Turn the CTE decoded bytes into unicode.
179+
# Turn the CTE decoded bytes into a string.
180180
try:
181181
string = bstring.decode(charset)
182182
except UnicodeDecodeError:

Lib/email/_policybase.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -365,7 +365,7 @@ def _fold(self, name, value, sanitize):
365365
charset=_charset.UNKNOWN8BIT,
366366
header_name=name)
367367
else:
368-
# If we have raw 8bit data in a byte string, we have no idea
368+
# If we have raw 8bit data in a string, we have no idea
369369
# what the encoding is. There is no safe way to split this
370370
# string. If it's ascii-subset, then we could do a normal
371371
# ascii split, but if it's multibyte then we could break the

0 commit comments

Comments
 (0)