[3.12] gh-106948: Add standard external names to nitpick_ignore (GH-106949)

Doc/c-api/arg.rst

@@ -70,7 +70,7 @@
 
 .. note::
 
    For all ``#`` variants of formats (``s#``, ``y#``, etc.), the macro
    :c:macro:`PY_SSIZE_T_CLEAN` must be defined before including
    :file:`Python.h`. On Python 3.9 and older, the type of the length argument
    is :c:type:`Py_ssize_t` if the :c:macro:`PY_SSIZE_T_CLEAN` macro is defined,
@@ -409,7 +409,7 @@
    Identical to :c:func:`PyArg_ParseTuple`, except that it accepts a va_list rather
    than a variable number of arguments.
 
 
 .. c:function:: int PyArg_ParseTupleAndKeywords(PyObject *args, PyObject *kw, const char *format, char *keywords[], ...)
 
    Parse the parameters of a function that takes both positional and keyword
@@ -429,7 +429,7 @@
    Identical to :c:func:`PyArg_ParseTupleAndKeywords`, except that it accepts a
    va_list rather than a variable number of arguments.
 
 
 .. c:function:: int PyArg_ValidateKeywordArguments(PyObject *)
 
    Ensure that the keys in the keywords argument dictionary are strings.  This
@@ -442,7 +442,7 @@
 .. XXX deprecated, will be removed
 .. c:function:: int PyArg_Parse(PyObject *args, const char *format, ...)
 
    Function used to deconstruct the argument lists of "old-style" functions ---
    these are functions which use the :const:`METH_OLDARGS` parameter parsing
    method, which has been removed in Python 3.  This is not recommended for use
    in parameter parsing in new code, and most code in the standard interpreter
@@ -468,7 +468,7 @@
    *args* is not a tuple or contains the wrong number of elements; an exception
    will be set if there was a failure.
 
    This is an example of the use of this function, taken from the sources for the
    :mod:`_weakref` helper module for weak references::
 
       static PyObject *
@@ -507,7 +507,7 @@
    whatever object is described by that format unit.  To force it to return a tuple
    of size 0 or one, parenthesize the format string.
 
    When memory buffers are passed as parameters to supply data to build objects, as
    for the ``s`` and ``s#`` formats, the required data is copied.  Buffers provided
    by the caller are never referenced by the objects created by
    :c:func:`Py_BuildValue`.  In other words, if your code invokes :c:func:`malloc`
@@ -547,7 +547,7 @@
       Same as ``s#``.
 
    ``u`` (:class:`str`) [const wchar_t \*]
-      Convert a null-terminated :c:expr:`wchar_t` buffer of Unicode (UTF-16 or UCS-4)
+      Convert a null-terminated :c:type:`wchar_t` buffer of Unicode (UTF-16 or UCS-4)
       data to a Python Unicode object.  If the Unicode buffer pointer is ``NULL``,
       ``None`` is returned.
 
@@ -651,4 +651,4 @@
 .. c:function:: PyObject* Py_VaBuildValue(const char *format, va_list vargs)
 
    Identical to :c:func:`Py_BuildValue`, except that it accepts a va_list
    rather than a variable number of arguments.

Doc/c-api/memory.rst

@@ -46,7 +46,7 @@
    single: realloc()
    single: free()
 
 To avoid memory corruption, extension writers should never try to operate on
 Python objects with the functions exported by the C library: :c:func:`malloc`,
 :c:func:`calloc`, :c:func:`realloc` and :c:func:`free`.  This will result in  mixed
 calls between the C allocator and the Python memory manager with fatal
@@ -581,7 +581,7 @@
     default).
 
     A serial number, incremented by 1 on each call to a malloc-like or
-    realloc-like function.  Big-endian ``size_t``.  If "bad memory" is detected
+    realloc-like function.  Big-endian :c:type:`size_t`.  If "bad memory" is detected
     later, the serial number gives an excellent way to set a breakpoint on the
     next run, to capture the instant at which this block was passed out.  The
     static function bumpserialno() in obmalloc.c is the only place the serial

Doc/c-api/unicode.rst

@@ -44,7 +44,7 @@ Python:
 
 .. c:type:: Py_UNICODE
 
-   This is a typedef of :c:expr:`wchar_t`, which is a 16-bit type or 32-bit type
+   This is a typedef of :c:type:`wchar_t`, which is a 16-bit type or 32-bit type
    depending on the platform.
 
    .. versionchanged:: 3.3
@@ -444,11 +444,11 @@ APIs:
    +----------+-----------------------------------------------------+
    | ``ll``   | :c:expr:`long long` or :c:expr:`unsigned long long` |
    +----------+-----------------------------------------------------+
-   | ``j``    | :c:expr:`intmax_t` or :c:expr:`uintmax_t`           |
+   | ``j``    | :c:type:`intmax_t` or :c:type:`uintmax_t`           |
    +----------+-----------------------------------------------------+
-   | ``z``    | :c:expr:`size_t` or :c:expr:`ssize_t`               |
+   | ``z``    | :c:type:`size_t` or :c:type:`ssize_t`               |
    +----------+-----------------------------------------------------+
-   | ``t``    | :c:expr:`ptrdiff_t`                                 |
+   | ``t``    | :c:type:`ptrdiff_t`                                 |
    +----------+-----------------------------------------------------+
 
    The length modifier ``l`` for following conversions ``s`` or ``V`` specify
@@ -527,7 +527,7 @@ APIs:
 
    .. note::
       The width formatter unit is number of characters rather than bytes.
-      The precision formatter unit is number of bytes or :c:expr:`wchar_t`
+      The precision formatter unit is number of bytes or :c:type:`wchar_t`
       items (if the length modifier ``l`` is used) for ``"%s"`` and
       ``"%V"`` (if the ``PyObject*`` argument is ``NULL``), and a number of
       characters for ``"%A"``, ``"%U"``, ``"%S"``, ``"%R"`` and ``"%V"``
@@ -846,21 +846,21 @@ conversion function:
 wchar_t Support
 """""""""""""""
 
-:c:expr:`wchar_t` support for platforms which support it:
+:c:type:`wchar_t` support for platforms which support it:
 
 .. c:function:: PyObject* PyUnicode_FromWideChar(const wchar_t *w, Py_ssize_t size)
 
-   Create a Unicode object from the :c:expr:`wchar_t` buffer *w* of the given *size*.
+   Create a Unicode object from the :c:type:`wchar_t` buffer *w* of the given *size*.
    Passing ``-1`` as the *size* indicates that the function must itself compute the length,
    using wcslen.
    Return ``NULL`` on failure.
 
 
 .. c:function:: Py_ssize_t PyUnicode_AsWideChar(PyObject *unicode, wchar_t *w, Py_ssize_t size)
 
-   Copy the Unicode object contents into the :c:expr:`wchar_t` buffer *w*.  At most
-   *size* :c:expr:`wchar_t` characters are copied (excluding a possibly trailing
-   null termination character).  Return the number of :c:expr:`wchar_t` characters
+   Copy the Unicode object contents into the :c:type:`wchar_t` buffer *w*.  At most
+   *size* :c:type:`wchar_t` characters are copied (excluding a possibly trailing
+   null termination character).  Return the number of :c:type:`wchar_t` characters
    copied or ``-1`` in case of an error.  Note that the resulting :c:expr:`wchar_t*`
    string may or may not be null-terminated.  It is the responsibility of the caller
    to make sure that the :c:expr:`wchar_t*` string is null-terminated in case this is
@@ -874,7 +874,7 @@ wchar_t Support
    Convert the Unicode object to a wide character string. The output string
    always ends with a null character. If *size* is not ``NULL``, write the number
    of wide characters (excluding the trailing null termination character) into
-   *\*size*. Note that the resulting :c:expr:`wchar_t` string might contain
+   *\*size*. Note that the resulting :c:type:`wchar_t` string might contain
    null characters, which would cause the string to be truncated when used with
    most C functions. If *size* is ``NULL`` and the :c:expr:`wchar_t*` string
    contains null characters a :exc:`ValueError` is raised.

Doc/c-api/veryhigh.rst

@@ -17,7 +17,7 @@ parameter.  The available start symbols are :c:data:`Py_eval_input`,
 following the functions which accept them as parameters.
 
 Note also that several of these functions take :c:expr:`FILE*` parameters.  One
-particular issue which needs to be handled carefully is that the :c:expr:`FILE`
+particular issue which needs to be handled carefully is that the :c:type:`FILE`
 structure for different C libraries can be different and incompatible.  Under
 Windows (at least), it is possible for dynamically linked extensions to actually
 use different libraries, so care should be taken that :c:expr:`FILE*` parameters

Doc/conf.py

@@ -77,6 +77,58 @@
     exclude_patterns.append(venvdir + '/*')
 
 nitpick_ignore = [
+    # Standard C types
+    ('c:type', 'FILE'),
+    ('c:type', '__int'),
+    ('c:type', 'intmax_t'),
+    ('c:type', 'off_t'),
+    ('c:type', 'ptrdiff_t'),
+    ('c:type', 'siginfo_t'),
+    ('c:type', 'size_t'),
+    ('c:type', 'ssize_t'),
+    ('c:type', 'time_t'),
+    ('c:type', 'uintmax_t'),
+    ('c:type', 'va_list'),
+    ('c:type', 'wchar_t'),
+    # Standard C macros
+    ('c:macro', 'LLONG_MAX'),
+    ('c:macro', 'LLONG_MIN'),
+    ('c:macro', 'LONG_MAX'),
+    ('c:macro', 'LONG_MIN'),
+    # Standard C variables
+    ('c:data', 'errno'),
+    # Standard environment variables
+    ('envvar', 'BROWSER'),
+    ('envvar', 'COLUMNS'),
+    ('envvar', 'COMSPEC'),
+    ('envvar', 'DISPLAY'),
+    ('envvar', 'HOME'),
+    ('envvar', 'HOMEDRIVE'),
+    ('envvar', 'HOMEPATH'),
+    ('envvar', 'IDLESTARTUP'),
+    ('envvar', 'LANG'),
+    ('envvar', 'LANGUAGE'),
+    ('envvar', 'LC_ALL'),
+    ('envvar', 'LC_CTYPE'),
+    ('envvar', 'LC_COLLATE'),
+    ('envvar', 'LC_MESSAGES'),
+    ('envvar', 'LC_MONETARY'),
+    ('envvar', 'LC_NUMERIC'),
+    ('envvar', 'LC_TIME'),
+    ('envvar', 'LINES'),
+    ('envvar', 'LOGNAME'),
+    ('envvar', 'PAGER'),
+    ('envvar', 'PATH'),
+    ('envvar', 'PATHEXT'),
+    ('envvar', 'SOURCE_DATE_EPOCH'),
+    ('envvar', 'TEMP'),
+    ('envvar', 'TERM'),
+    ('envvar', 'TMP'),
+    ('envvar', 'TMPDIR'),
+    ('envvar', 'TZ'),
+    ('envvar', 'USER'),
+    ('envvar', 'USERNAME'),
+    ('envvar', 'USERPROFILE'),
     # Do not error nit-picky mode builds when _SubParsersAction.add_parser cannot
     # be resolved, as the method is currently undocumented. For context, see
     # https://github.com/python/cpython/pull/103289.

Doc/library/array.rst

@@ -51,9 +51,9 @@ Notes:
    It can be 16 bits or 32 bits depending on the platform.
 
    .. versionchanged:: 3.9
-      ``array('u')`` now uses ``wchar_t`` as C type instead of deprecated
+      ``array('u')`` now uses :c:type:`wchar_t` as C type instead of deprecated
       ``Py_UNICODE``. This change doesn't affect its behavior because
-      ``Py_UNICODE`` is alias of ``wchar_t`` since Python 3.3.
+      ``Py_UNICODE`` is alias of :c:type:`wchar_t` since Python 3.3.
 
    .. deprecated-removed:: 3.3 4.0
 

Doc/library/ctypes.rst

@@ -220,7 +220,7 @@ Fundamental data types
 +----------------------+------------------------------------------+----------------------------+
 | :class:`c_char`      | :c:expr:`char`                           | 1-character bytes object   |
 +----------------------+------------------------------------------+----------------------------+
-| :class:`c_wchar`     | :c:expr:`wchar_t`                        | 1-character string         |
+| :class:`c_wchar`     | :c:type:`wchar_t`                        | 1-character string         |
 +----------------------+------------------------------------------+----------------------------+
 | :class:`c_byte`      | :c:expr:`char`                           | int                        |
 +----------------------+------------------------------------------+----------------------------+
@@ -243,9 +243,9 @@ Fundamental data types
 | :class:`c_ulonglong` | :c:expr:`unsigned __int64` or            | int                        |
 |                      | :c:expr:`unsigned long long`             |                            |
 +----------------------+------------------------------------------+----------------------------+
-| :class:`c_size_t`    | :c:expr:`size_t`                         | int                        |
+| :class:`c_size_t`    | :c:type:`size_t`                         | int                        |
 +----------------------+------------------------------------------+----------------------------+
-| :class:`c_ssize_t`   | :c:expr:`ssize_t` or                     | int                        |
+| :class:`c_ssize_t`   | :c:type:`ssize_t` or                     | int                        |
 |                      | :c:expr:`Py_ssize_t`                     |                            |
 +----------------------+------------------------------------------+----------------------------+
 | :class:`c_time_t`    | :c:type:`time_t`                         | int                        |
@@ -335,7 +335,7 @@ property::
 
 The :func:`create_string_buffer` function replaces the old :func:`c_buffer`
 function (which is still available as an alias).  To create a mutable memory
-block containing unicode characters of the C type :c:expr:`wchar_t`, use the
+block containing unicode characters of the C type :c:type:`wchar_t`, use the
 :func:`create_unicode_buffer` function.
 
 
@@ -478,7 +478,7 @@ By default functions are assumed to return the C :c:expr:`int` type.  Other
 return types can be specified by setting the :attr:`restype` attribute of the
 function object.
 
-The C prototype of ``time()`` is ``time_t time(time_t *)``. Because ``time_t``
+The C prototype of ``time()`` is ``time_t time(time_t *)``. Because :c:type:`time_t`
 might be of a different type than the default return type ``int``, you should
 specify the ``restype``::
 
@@ -2407,7 +2407,7 @@ These are the fundamental ctypes data types:
 
 .. class:: c_wchar
 
-   Represents the C :c:expr:`wchar_t` datatype, and interprets the value as a
+   Represents the C :c:type:`wchar_t` datatype, and interprets the value as a
    single character unicode string.  The constructor accepts an optional string
    initializer, the length of the string must be exactly one character.
 

Doc/library/os.rst

@@ -4650,7 +4650,7 @@ written in Python, such as a mail server's external command delivery program.
    :data:`WNOHANG` and :data:`WNOWAIT` are additional optional flags.
 
    The return value is an object representing the data contained in the
-   :c:type:`!siginfo_t` structure with the following attributes:
+   :c:type:`siginfo_t` structure with the following attributes:
 
    * :attr:`!si_pid` (process ID)
    * :attr:`!si_uid` (real user ID of the child)

Doc/library/struct.rst

@@ -231,9 +231,9 @@ platform-dependent.
 | ``Q``  | :c:expr:`unsigned long   | integer            | 8              | \(2)       |
 |        | long`                    |                    |                |            |
 +--------+--------------------------+--------------------+----------------+------------+
-| ``n``  | :c:expr:`ssize_t`        | integer            |                | \(3)       |
+| ``n``  | :c:type:`ssize_t`        | integer            |                | \(3)       |
 +--------+--------------------------+--------------------+----------------+------------+
-| ``N``  | :c:expr:`size_t`         | integer            |                | \(3)       |
+| ``N``  | :c:type:`size_t`         | integer            |                | \(3)       |
 +--------+--------------------------+--------------------+----------------+------------+
 | ``e``  | \(6)                     | float              | 2              | \(4)       |
 +--------+--------------------------+--------------------+----------------+------------+

Doc/library/venv.rst

@@ -60,7 +60,7 @@ running from a virtual environment.
 
 A virtual environment may be "activated" using a script in its binary directory
 (``bin`` on POSIX; ``Scripts`` on Windows).
-This will prepend that directory to your :envvar:`!PATH`, so that running
+This will prepend that directory to your :envvar:`PATH`, so that running
 :program:`python` will invoke the environment's Python interpreter
 and you can run installed scripts without having to use their full path.
 The invocation of the activation script is platform-specific
@@ -100,10 +100,10 @@ In order to achieve this, scripts installed into virtual environments have
 a "shebang" line which points to the environment's Python interpreter,
 i.e. :samp:`#!/{<path-to-venv>}/bin/python`.
 This means that the script will run with that interpreter regardless of the
-value of :envvar:`!PATH`. On Windows, "shebang" line processing is supported if
+value of :envvar:`PATH`. On Windows, "shebang" line processing is supported if
 you have the :ref:`launcher` installed. Thus, double-clicking an installed
 script in a Windows Explorer window should run it with the correct interpreter
-without the environment needing to be activated or on the :envvar:`!PATH`.
+without the environment needing to be activated or on the :envvar:`PATH`.
 
 When a virtual environment has been activated, the :envvar:`!VIRTUAL_ENV`
 environment variable is set to the path of the environment.

Doc/tools/.nitignore

@@ -100,7 +100,6 @@ Doc/library/codecs.rst
 Doc/library/codeop.rst
 Doc/library/collections.abc.rst
 Doc/library/collections.rst
-Doc/library/compileall.rst
 Doc/library/concurrent.futures.rst
 Doc/library/concurrent.rst
 Doc/library/configparser.rst
@@ -109,8 +108,6 @@ Doc/library/contextlib.rst
 Doc/library/copy.rst
 Doc/library/csv.rst
 Doc/library/ctypes.rst
-Doc/library/curses.ascii.rst
-Doc/library/curses.rst
 Doc/library/datetime.rst
 Doc/library/dbm.rst
 Doc/library/decimal.rst
@@ -148,7 +145,6 @@ Doc/library/http.client.rst
 Doc/library/http.cookiejar.rst
 Doc/library/http.cookies.rst
 Doc/library/http.server.rst
-Doc/library/idle.rst
 Doc/library/importlib.resources.abc.rst
 Doc/library/importlib.resources.rst
 Doc/library/importlib.rst
@@ -179,11 +175,9 @@ Doc/library/pickletools.rst
 Doc/library/platform.rst
 Doc/library/plistlib.rst
 Doc/library/poplib.rst
-Doc/library/posix.rst
 Doc/library/pprint.rst
 Doc/library/profile.rst
 Doc/library/pty.rst
-Doc/library/py_compile.rst
 Doc/library/pyclbr.rst
 Doc/library/pydoc.rst
 Doc/library/pyexpat.rst
@@ -206,7 +200,6 @@ Doc/library/ssl.rst
 Doc/library/stat.rst
 Doc/library/stdtypes.rst
 Doc/library/string.rst
-Doc/library/struct.rst
 Doc/library/subprocess.rst
 Doc/library/sunau.rst
 Doc/library/sys.rst
@@ -273,7 +266,6 @@ Doc/tutorial/modules.rst
 Doc/tutorial/stdlib2.rst
 Doc/using/cmdline.rst
 Doc/using/configure.rst
-Doc/using/unix.rst
 Doc/using/windows.rst
 Doc/whatsnew/2.0.rst
 Doc/whatsnew/2.1.rst

Doc/whatsnew/3.12.rst

@@ -1768,7 +1768,7 @@ Porting to Python 3.12
   for example).
 
 * Add support of more formatting options (left aligning, octals, uppercase
-  hexadecimals, ``intmax_t``, ``ptrdiff_t``, ``wchar_t`` C
+  hexadecimals, :c:type:`intmax_t`, :c:type:`ptrdiff_t`, :c:type:`wchar_t` C
   strings, variable width and precision) in :c:func:`PyUnicode_FromFormat` and
   :c:func:`PyUnicode_FromFormatV`.
   (Contributed by Serhiy Storchaka in :gh:`98836`.)

Doc/whatsnew/3.3.rst

@@ -1984,7 +1984,7 @@ the form '-rwxrwxrwx'.
 struct
 ------
 
-The :mod:`struct` module now supports ``ssize_t`` and ``size_t`` via the
+The :mod:`struct` module now supports :c:type:`ssize_t` and :c:type:`size_t` via the
 new codes ``n`` and ``N``, respectively.  (Contributed by Antoine Pitrou
 in :issue:`3163`.)
 

Doc/whatsnew/3.5.rst

@@ -2192,7 +2192,7 @@ encode error with ``\N{...}`` escapes.
 (Contributed by Serhiy Storchaka in :issue:`19676`.)
 
 A new :c:func:`PyErr_FormatV` function similar to :c:func:`PyErr_Format`,
-but accepts a ``va_list`` argument.
+but accepts a :c:type:`va_list` argument.
 (Contributed by Antoine Pitrou in :issue:`18711`.)
 
 A new :c:data:`PyExc_RecursionError` exception.

Doc/whatsnew/3.9.rst

@@ -1115,9 +1115,9 @@ Changes in the Python API
   ``PyCF_ALLOW_TOP_LEVEL_AWAIT`` was clashing with ``CO_FUTURE_DIVISION``.
   (Contributed by Batuhan Taskaya in :issue:`39562`)
 
-* ``array('u')`` now uses ``wchar_t`` as C type instead of ``Py_UNICODE``.
+* ``array('u')`` now uses :c:type:`wchar_t` as C type instead of ``Py_UNICODE``.
   This change doesn't affect to its behavior because ``Py_UNICODE`` is alias
-  of ``wchar_t`` since Python 3.3.
+  of :c:type:`wchar_t` since Python 3.3.
   (Contributed by Inada Naoki in :issue:`34538`.)
 
 * The :func:`logging.getLogger` API now returns the root logger when passed

Misc/NEWS.d/3.10.0a5.rst

@@ -667,4 +667,4 @@ exception (if an exception is set). Patch by Victor Stinner.
 .. section: C API
 
 Fixed a compiler warning in :c:func:`Py_UNICODE_ISSPACE()` on platforms with
-signed ``wchar_t``.
+signed :c:type:`wchar_t`.

Misc/NEWS.d/3.12.0a1.rst

@@ -5308,7 +5308,7 @@ parameter. Patch by Kumar Aditya.
 .. section: Build
 
 Python now always use the ``%zu`` and ``%zd`` printf formats to format a
-``size_t`` or ``Py_ssize_t`` number. Building Python 3.12 requires a C11
+:c:type:`size_t` or ``Py_ssize_t`` number. Building Python 3.12 requires a C11
 compiler, so these printf formats are now always supported. Patch by Victor
 Stinner.
 

Misc/NEWS.d/3.12.0b1.rst

@@ -2382,7 +2382,7 @@ Patch by Dong-hee Na.
 .. section: C API
 
 Add support of more formatting options (left aligning, octals, uppercase
-hexadecimals, :c:expr:`intmax_t`, :c:expr:`ptrdiff_t`, :c:expr:`wchar_t` C
+hexadecimals, :c:type:`intmax_t`, :c:type:`ptrdiff_t`, :c:type:`wchar_t` C
 strings, variable width and precision) in :c:func:`PyUnicode_FromFormat` and
 :c:func:`PyUnicode_FromFormatV`.
 

Misc/NEWS.d/next/Documentation/2023-07-21-11-51-57.gh-issue-106948.K_JQ7j.rst

@@ -0,0 +1 @@
+Add a number of standard external names to ``nitpick_ignore``.