Skip to content

Commit

Permalink
[3.11] gh-93738: Disallow pre-v3 syntax in the C domain (GH-97962) (#…
Browse files Browse the repository at this point in the history
…97976)

Also, disable using invalid sphinx-lint 0.6.2.
(cherry picked from commit f612565)

Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
  • Loading branch information
3 people authored and pablogsal committed Oct 22, 2022
1 parent cc10a8e commit bf1de26
Show file tree
Hide file tree
Showing 8 changed files with 18 additions and 28 deletions.
12 changes: 6 additions & 6 deletions Doc/c-api/unicode.rst
Original file line number Diff line number Diff line change
Expand Up @@ -17,8 +17,8 @@ of Unicode characters while staying memory efficient. There are special cases
for strings where all code points are below 128, 256, or 65536; otherwise, code
points must be below 1114112 (which is the full Unicode range).

:c:type:`Py_UNICODE*` and UTF-8 representations are created on demand and cached
in the Unicode object. The :c:type:`Py_UNICODE*` representation is deprecated
:c:expr:`Py_UNICODE*` and UTF-8 representations are created on demand and cached
in the Unicode object. The :c:expr:`Py_UNICODE*` representation is deprecated
and inefficient.

Due to the transition between the old APIs and the new APIs, Unicode objects
Expand All @@ -30,7 +30,7 @@ can internally be in two states depending on how they were created:

* "legacy" Unicode objects have been created through one of the deprecated
APIs (typically :c:func:`PyUnicode_FromUnicode`) and only bear the
:c:type:`Py_UNICODE*` representation; you will have to call
:c:expr:`Py_UNICODE*` representation; you will have to call
:c:func:`PyUnicode_READY` on them before calling any other API.

.. note::
Expand Down Expand Up @@ -236,7 +236,7 @@ access to internal read-only data of Unicode objects:
returned buffer is always terminated with an extra null code point. It
may also contain embedded null code points, which would cause the string
to be truncated when used in most C functions. The ``AS_DATA`` form
casts the pointer to :c:type:`const char *`. The *o* argument has to be
casts the pointer to :c:expr:`const char *`. The *o* argument has to be
a Unicode object (not checked).
.. versionchanged:: 3.3
Expand Down Expand Up @@ -714,7 +714,7 @@ Extension modules can continue using them, as they will not be removed in Python
Return a read-only pointer to the Unicode object's internal
:c:type:`Py_UNICODE` buffer, or ``NULL`` on error. This will create the
:c:type:`Py_UNICODE*` representation of the object if it is not yet
:c:expr:`Py_UNICODE*` representation of the object if it is not yet
available. The buffer is always terminated with an extra null code point.
Note that the resulting :c:type:`Py_UNICODE` string may also contain
embedded null code points, which would cause the string to be truncated when
Expand All @@ -730,7 +730,7 @@ Extension modules can continue using them, as they will not be removed in Python
Like :c:func:`PyUnicode_AsUnicode`, but also saves the :c:func:`Py_UNICODE`
array length (excluding the extra null terminator) in *size*.
Note that the resulting :c:type:`Py_UNICODE*` string
Note that the resulting :c:expr:`Py_UNICODE*` string
may contain embedded null code points, which would cause the string to be
truncated when used in most C functions.
Expand Down
10 changes: 0 additions & 10 deletions Doc/conf.py
Original file line number Diff line number Diff line change
Expand Up @@ -234,13 +234,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
14 changes: 7 additions & 7 deletions Doc/extending/newtypes.rst
Original file line number Diff line number Diff line change
Expand Up @@ -207,8 +207,8 @@ 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:type:`char\*`, while the other
accepts a :c:type:`PyObject\*`. Each type can use whichever pair makes more
pair takes the name of the attribute as a :c:expr:`char\*`, while the other
accepts a :c:expr:`PyObject*`. Each type can use whichever pair makes more
sense for the implementation's convenience. ::

getattrfunc tp_getattr; /* char * version */
Expand All @@ -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.
Expand Down Expand Up @@ -339,9 +339,9 @@ of ``NULL`` is required.
Type-specific Attribute Management
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For simplicity, only the :c:type:`char\*` version will be demonstrated here; the
type of the name parameter is the only difference between the :c:type:`char\*`
and :c:type:`PyObject\*` flavors of the interface. This example effectively does
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: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
Expand Down Expand Up @@ -572,7 +572,7 @@ performance-critical objects (such as numbers).

For an object to be weakly referencable, the extension type must do two things:

#. Include a :c:type:`PyObject\*` field in the C object structure dedicated to
#. Include a :c:expr:`PyObject*` field in the C object structure dedicated to
the weak reference mechanism. The object's constructor should leave it
``NULL`` (which is automatic when using the default
:c:member:`~PyTypeObject.tp_alloc`).
Expand Down
2 changes: 1 addition & 1 deletion Doc/extending/newtypes_tutorial.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion Doc/howto/isolating-extensions.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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::

Expand Down
2 changes: 1 addition & 1 deletion Doc/requirements.txt
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ blurb
# 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==0.6.1
sphinx-lint<1,!=0.6.2

# The theme used by the documentation is stored separately, so we need
# to install that as well.
Expand Down
2 changes: 1 addition & 1 deletion Doc/whatsnew/2.2.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion Doc/whatsnew/2.5.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down

0 comments on commit bf1de26

Please sign in to comment.