[Python-checkins] gh-93738: Disallow pre-v3 syntax in the C domain (#97962)
ambv
webhook-mailer at python.org
Thu Oct 6 13:11:46 EDT 2022
https://github.com/python/cpython/commit/f612565bd32d4ab0945798da775eea070f08b6fe
commit: f612565bd32d4ab0945798da775eea070f08b6fe
branch: main
author: Adam Turner <9087854+AA-Turner at users.noreply.github.com>
committer: ambv <lukasz at langa.pl>
date: 2022-10-06T10:11:37-07:00
summary:
gh-93738: Disallow pre-v3 syntax in the C domain (#97962)
Also, disable using invalid sphinx-lint 0.6.2.
files:
M Doc/conf.py
M Doc/extending/newtypes.rst
M Doc/extending/newtypes_tutorial.rst
M Doc/howto/isolating-extensions.rst
M Doc/requirements.txt
M Doc/whatsnew/2.2.rst
M Doc/whatsnew/2.5.rst
diff --git a/Doc/conf.py b/Doc/conf.py
index 909f992d9d82..be1c9fff51a2 100644
--- a/Doc/conf.py
+++ b/Doc/conf.py
@@ -239,28 +239,3 @@
# Relative filename of the data files
refcount_file = 'data/refcounts.dat'
stable_abi_file = 'data/stable_abi.dat'
-
-# Sphinx 2 and Sphinx 3 compatibility
-# -----------------------------------
-
-# bpo-40204: Allow Sphinx 2 syntax in the C domain
-c_allow_pre_v3 = True
-
-# bpo-40204: Disable warnings on Sphinx 2 syntax of the C domain since the
-# documentation is built with -W (warnings treated as errors).
-c_warn_on_allowed_pre_v3 = False
-
-# Fix '!' not working with C domain when pre_v3 is enabled
-import sphinx
-
-if sphinx.version_info[:2] < (5, 3):
- from sphinx.domains.c import CXRefRole
-
- original_run = CXRefRole.run
-
- def new_run(self):
- if self.disabled:
- return super(CXRefRole, self).run()
- return original_run(self)
-
- CXRefRole.run = new_run
diff --git a/Doc/extending/newtypes.rst b/Doc/extending/newtypes.rst
index a076eae534b9..3de849ade788 100644
--- a/Doc/extending/newtypes.rst
+++ b/Doc/extending/newtypes.rst
@@ -208,7 +208,7 @@ a special case, for which the new value passed to the handler is ``NULL``.
Python supports two pairs of attribute handlers; a type that supports attributes
only needs to implement the functions for one pair. The difference is that one
pair takes the name of the attribute as a :c:expr:`char\*`, while the other
-accepts a :c:type:`PyObject\*`. Each type can use whichever pair makes more
+accepts a :c:expr:`PyObject*`. Each type can use whichever pair makes more
sense for the implementation's convenience. ::
getattrfunc tp_getattr; /* char * version */
@@ -219,7 +219,7 @@ sense for the implementation's convenience. ::
If accessing attributes of an object is always a simple operation (this will be
explained shortly), there are generic implementations which can be used to
-provide the :c:type:`PyObject\*` version of the attribute management functions.
+provide the :c:expr:`PyObject*` version of the attribute management functions.
The actual need for type-specific attribute handlers almost completely
disappeared starting with Python 2.2, though there are many examples which have
not been updated to use some of the new generic mechanism that is available.
@@ -341,7 +341,7 @@ Type-specific Attribute Management
For simplicity, only the :c:expr:`char\*` version will be demonstrated here; the
type of the name parameter is the only difference between the :c:expr:`char\*`
-and :c:type:`PyObject\*` flavors of the interface. This example effectively does
+and :c:expr:`PyObject*` flavors of the interface. This example effectively does
the same thing as the generic example above, but does not use the generic
support added in Python 2.2. It explains how the handler functions are
called, so that if you do need to extend their functionality, you'll understand
diff --git a/Doc/extending/newtypes_tutorial.rst b/Doc/extending/newtypes_tutorial.rst
index 34c25d1f6f19..5d4a3f06dd54 100644
--- a/Doc/extending/newtypes_tutorial.rst
+++ b/Doc/extending/newtypes_tutorial.rst
@@ -24,7 +24,7 @@ The Basics
==========
The :term:`CPython` runtime sees all Python objects as variables of type
-:c:type:`PyObject\*`, which serves as a "base type" for all Python objects.
+:c:expr:`PyObject*`, which serves as a "base type" for all Python objects.
The :c:type:`PyObject` structure itself only contains the object's
:term:`reference count` and a pointer to the object's "type object".
This is where the action is; the type object determines which (C) functions
diff --git a/Doc/howto/isolating-extensions.rst b/Doc/howto/isolating-extensions.rst
index 8ee7e5e28479..2657b4ec6aaf 100644
--- a/Doc/howto/isolating-extensions.rst
+++ b/Doc/howto/isolating-extensions.rst
@@ -411,7 +411,7 @@ that subclass, which may be defined in different module than yours.
pass
For a method to get its "defining class", it must use the
-:c:data:`METH_METHOD | METH_FASTCALL | METH_KEYWORDS`
+:data:`METH_METHOD | METH_FASTCALL | METH_KEYWORDS`
:c:type:`calling convention <PyMethodDef>`
and the corresponding :c:type:`PyCMethod` signature::
diff --git a/Doc/requirements.txt b/Doc/requirements.txt
index f8a7f9db144c..be058733fcf4 100644
--- a/Doc/requirements.txt
+++ b/Doc/requirements.txt
@@ -7,7 +7,10 @@ sphinx==4.5.0
blurb
-sphinx-lint<1
+# sphinx-lint 0.6.2 yields many default role errors due to the new regular
+# expression used for default role detection, so we don't use the version
+# until the errors are fixed.
+sphinx-lint<1,!=0.6.2
# The theme used by the documentation is stored separately, so we need
# to install that as well.
diff --git a/Doc/whatsnew/2.2.rst b/Doc/whatsnew/2.2.rst
index bfb2aacbc077..39997661bb96 100644
--- a/Doc/whatsnew/2.2.rst
+++ b/Doc/whatsnew/2.2.rst
@@ -1102,7 +1102,7 @@ code, none of the changes described here will affect you very much.
* A different argument parsing function, :c:func:`PyArg_UnpackTuple`, has been
added that's simpler and presumably faster. Instead of specifying a format
string, the caller simply gives the minimum and maximum number of arguments
- expected, and a set of pointers to :c:type:`PyObject\*` variables that will be
+ expected, and a set of pointers to :c:expr:`PyObject*` variables that will be
filled in with argument values.
* Two new flags :const:`METH_NOARGS` and :const:`METH_O` are available in method
diff --git a/Doc/whatsnew/2.5.rst b/Doc/whatsnew/2.5.rst
index 0aca2fe697cc..dcfaef6ed294 100644
--- a/Doc/whatsnew/2.5.rst
+++ b/Doc/whatsnew/2.5.rst
@@ -1725,7 +1725,7 @@ attribute of the function object to change this::
``ctypes.pythonapi`` object. This object does *not* release the global
interpreter lock before calling a function, because the lock must be held when
calling into the interpreter's code. There's a :class:`py_object()` type
-constructor that will create a :c:type:`PyObject \*` pointer. A simple usage::
+constructor that will create a :c:expr:`PyObject *` pointer. A simple usage::
import ctypes
More information about the Python-checkins
mailing list