Closes #23181: codepoint -> code point

diff --git a/Doc/c-api/unicode.rst b/Doc/c-api/unicode.rst
index 8932915da9b0e2868cd617269ac36ec4ba40cddb..13a28075bb7061f8b2b190e35d23d7af27ed0120 100644 (file)
--- a/Doc/c-api/unicode.rst
+++ b/Doc/c-api/unicode.rst
@@ -547,7 +547,7 @@ These are the UTF-32 codec APIs:
    After completion, *\*byteorder* is set to the current byte order at the end
    of input data.
 
-   In a narrow build codepoints outside the BMP will be decoded as surrogate pairs.
+   In a narrow build code points outside the BMP will be decoded as surrogate pairs.
 
    If *byteorder* is *NULL*, the codec starts in native order mode.
 
@@ -580,7 +580,7 @@ These are the UTF-32 codec APIs:
    mark (U+FEFF). In the other two modes, no BOM mark is prepended.
 
    If *Py_UNICODE_WIDE* is not defined, surrogate pairs will be output
-   as a single codepoint.
+   as a single code point.
 
    Return *NULL* if an exception was raised by the codec.
 

diff --git a/Doc/library/codecs.rst b/Doc/library/codecs.rst
index 05c715623bf87b6f74d1d2e77b555a6d375fdb46..feeb23628999c9fffc8c87b67a2060c8144ddd79 100644 (file)
--- a/Doc/library/codecs.rst
+++ b/Doc/library/codecs.rst
@@ -787,7 +787,7 @@ methods and attributes from the underlying stream.
 Encodings and Unicode
 ---------------------
 
-Unicode strings are stored internally as sequences of codepoints (to be precise
+Unicode strings are stored internally as sequences of code points (to be precise
 as :c:type:`Py_UNICODE` arrays). Depending on the way Python is compiled (either
 via ``--enable-unicode=ucs2`` or ``--enable-unicode=ucs4``, with the
 former being the default) :c:type:`Py_UNICODE` is either a 16-bit or 32-bit data
@@ -796,24 +796,24 @@ and how these arrays are stored as bytes become an issue.  Transforming a
 unicode object into a sequence of bytes is called encoding and recreating the
 unicode object from the sequence of bytes is known as decoding.  There are many
 different methods for how this transformation can be done (these methods are
-also called encodings). The simplest method is to map the codepoints 0-255 to
+also called encodings). The simplest method is to map the code points 0-255 to
 the bytes ``0x0``-``0xff``. This means that a unicode object that contains
-codepoints above ``U+00FF`` can't be encoded with this method (which is called
+code points above ``U+00FF`` can't be encoded with this method (which is called
 ``'latin-1'`` or ``'iso-8859-1'``). :func:`unicode.encode` will raise a
 :exc:`UnicodeEncodeError` that looks like this: ``UnicodeEncodeError: 'latin-1'
 codec can't encode character u'\u1234' in position 3: ordinal not in
 range(256)``.
 
 There's another group of encodings (the so called charmap encodings) that choose
-a different subset of all unicode code points and how these codepoints are
+a different subset of all unicode code points and how these code points are
 mapped to the bytes ``0x0``-``0xff``. To see how this is done simply open
 e.g. :file:`encodings/cp1252.py` (which is an encoding that is used primarily on
 Windows). There's a string constant with 256 characters that shows you which
 character is mapped to which byte value.
 
-All of these encodings can only encode 256 of the 1114112 codepoints
+All of these encodings can only encode 256 of the 1114112 code points
 defined in unicode. A simple and straightforward way that can store each Unicode
-code point, is to store each codepoint as four consecutive bytes. There are two
+code point, is to store each code point as four consecutive bytes. There are two
 possibilities: store the bytes in big endian or in little endian order. These
 two encodings are called ``UTF-32-BE`` and ``UTF-32-LE`` respectively. Their
 disadvantage is that if e.g. you use ``UTF-32-BE`` on a little endian machine you

diff --git a/Doc/library/htmllib.rst b/Doc/library/htmllib.rst
index 9e68f4596c5d2e87287c43a9da61ef3faf898da9..d9d81dfe2ebb230b6671b7551f51d7aa5f095de9 100644 (file)
--- a/Doc/library/htmllib.rst
+++ b/Doc/library/htmllib.rst
@@ -185,14 +185,14 @@ can be handled using simple textual substitution in the Latin-1 character set
 
 .. data:: name2codepoint
 
-   A dictionary that maps HTML entity names to the Unicode codepoints.
+   A dictionary that maps HTML entity names to the Unicode code points.
 
    .. versionadded:: 2.3
 
 
 .. data:: codepoint2name
 
-   A dictionary that maps Unicode codepoints to HTML entity names.
+   A dictionary that maps Unicode code points to HTML entity names.
 
    .. versionadded:: 2.3
 

diff --git a/Doc/library/json.rst b/Doc/library/json.rst
index db9df0a247c073fc3486bf07f7fee45fa8517fe3..6db8f97cc0e03669bc9989d3f68155d05fa23e0c 100644 (file)
--- a/Doc/library/json.rst
+++ b/Doc/library/json.rst
@@ -533,7 +533,7 @@ The RFC does not explicitly forbid JSON strings which contain byte sequences
 that don't correspond to valid Unicode characters (e.g. unpaired UTF-16
 surrogates), but it does note that they may cause interoperability problems.
 By default, this module accepts and outputs (when present in the original
-:class:`str`) codepoints for such sequences.
+:class:`str`) code points for such sequences.
 
 
 Infinite and NaN Number Values

diff --git a/Doc/tutorial/interpreter.rst b/Doc/tutorial/interpreter.rst
index 19094f3e2ad0ef1d11d26d1ba20739c4501ae69a..67f927fdf522c0c2df46a5c79defae4442d404f6 100644 (file)
--- a/Doc/tutorial/interpreter.rst
+++ b/Doc/tutorial/interpreter.rst
@@ -140,7 +140,7 @@ encodings can be found in the Python Library Reference, in the section on
 For example, to write Unicode literals including the Euro currency symbol, the
 ISO-8859-15 encoding can be used, with the Euro symbol having the ordinal value
 164.  This script, when saved in the ISO-8859-15 encoding, will print the value
-8364 (the Unicode codepoint corresponding to the Euro symbol) and then exit::
+8364 (the Unicode code point corresponding to the Euro symbol) and then exit::
 
    # -*- coding: iso-8859-15 -*-