From: Georg Brandl Date: Wed, 14 Jan 2015 07:26:30 +0000 (+0100) Subject: Closes #23181: codepoint -> code point X-Git-Tag: v2.7.10rc1~231 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=a44ec3ff4cdf0378acda7c12a3b8c586eca86682;p=python Closes #23181: codepoint -> code point --- diff --git a/Doc/c-api/unicode.rst b/Doc/c-api/unicode.rst index 8932915da9..13a28075bb 100644 --- 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 05c715623b..feeb236289 100644 --- 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 9e68f4596c..d9d81dfe2e 100644 --- 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 db9df0a247..6db8f97cc0 100644 --- 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 19094f3e2a..67f927fdf5 100644 --- 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 -*-