8000 [3.12] gh-107298: Fix some references in the C API documentation (GH-… · python/cpython@41c951b · GitHub
[go: up one dir, main page]
Skip to content

Commit 41c951b

Browse files
miss-islingtonserhiy-storchaka
miss-islington
and
serhiy-storchaka
authored
[3.12] gh-107298: Fix some references in the C API documentation (GH-108072) (#108074)
gh-107298: Fix some references in the C API documentation (GH-108072) (cherry picked from commit f51f046) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
1 parent 125aab9 commit 41c951b

File tree

11 files changed

+20
-20
lines changed

11< 10000 !-- --> files changed

+20
-20
lines changed

‎Doc/c-api/typeobj.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1697,7 +1697,7 @@ and :c:data:`PyType_Type` effectively act as defaults.)
16971697
to a pointer, are valid C99 address constants.
16981698

16991699
However, the unary '&' operator applied to a non-static variable
1700-
like :c:func:`PyBaseObject_Type` is not required to produce an address
1700+
like :c:data:`PyBaseObject_Type` is not required to produce an address
17011701
constant. Compilers may support this (gcc does), MSVC does not.
17021702
Both compilers are strictly standard conforming in this particular
17031703
behavior.

‎Doc/extending/extending.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -242,7 +242,7 @@ needed to ensure that it will not be discarded, causing :c:data:`!SpamError` to
242242
become a dangling pointer. Should it become a dangling pointer, C code which
243243
raises the exception could cause a core dump or other unintended side effects.
244244

245-
We discuss the use of ``PyMODINIT_FUNC`` as a function return type later in this
245+
We discuss the use of :c:macro:`PyMODINIT_FUNC` as a function return type later in this
246246
sample.
247247

248248
The :exc:`!spam.error` exception can be raised in your extension module using a
@@ -363,7 +363,7 @@ only non-\ ``static`` item defined in the module file::
363363
return PyModule_Create(&spammodule);
364364
}
365365

366-
Note that PyMODINIT_FUNC declares the function as ``PyObject *`` return type,
366+
Note that :c:macro:`PyMODINIT_FUNC` declares the function as ``PyObject *`` return type,
367367
declares any special linkage declarations required by the platform, and for C++
368368
declares the function as ``extern "C"``.
369369

‎Doc/using/configure.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -746,8 +746,8 @@ Example on Linux x86-64::
746746
At the beginning of the files, C extensions are built as built-in modules.
747747
Extensions defined after the ``*shared*`` marker are built as dynamic libraries.
748748

749-
The :c:macro:`PyAPI_FUNC()`, :c:macro:`PyAPI_API()` and
750-
:c:macro:`PyMODINIT_FUNC()` macros of :file:`Include/pyport.h` are defined
749+
The :c:macro:`PyAPI_FUNC()`, :c:macro:`PyAPI_DATA()` and
750+
:c:macro:`PyMODINIT_FUNC` macros of :file:`Include/pyport.h` are defined
751751
differently depending if the ``Py_BUILD_CORE_MODULE`` macro is defined:
752752

753753
* Use ``Py_EXPORTED_SYMBOL`` if the ``Py_BUILD_CORE_MODULE`` is defined

‎Doc/whatsnew/2.2.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1109,7 +1109,7 @@ code, none of the changes described here will affect you very much.
11091109
definition tables to simplify implementation of methods with no arguments or a
11101110
single untyped argument. Calling such methods is more efficient than calling a
11111111
corresponding method that uses :c:macro:`METH_VARARGS`. Also, the old
1112-
:c:macro:`METH_OLDARGS` style of writing C methods is now officially deprecated.
1112+
:c:macro:`!METH_OLDARGS` style of writing C methods is now officially deprecated.
11131113

11141114
* Two new wrapper functions, :c:func:`PyOS_snprintf` and :c:func:`PyOS_vsnprintf`
11151115
were added to provide cross-platform implementations for the relatively new

‎Doc/whatsnew/2.3.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1886,7 +1886,7 @@ Changes to Python's build process and to the C API include:
18861886
(:file:`libpython2.3.so`) by supplying :option:`!--enable-shared` when running
18871887
Python's :program:`configure` script. (Contributed by Ondrej Palkovsky.)
18881888

1889-
* The :c:macro:`DL_EXPORT` and :c:macro:`DL_IMPORT` macros are now deprecated.
1889+
* The :c:macro:`!DL_EXPORT` and :c:macro:`!DL_IMPORT` macros are now deprecated.
18901890
Initialization functions for Python extension modules should now be declared
18911891
using the new macro :c:macro:`PyMODINIT_FUNC`, while the Python core will
18921892
generally use the :c:macro:`PyAPI_FUNC` and :c:macro:`PyAPI_DATA` macros.

‎Doc/whatsnew/2.4.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1476,7 +1476,7 @@ Some of the changes to Python's build process and to the C API are:
14761476
:c:func:`PyArg_ParseTupleAndKeywords` but takes a :c:type:`va_list` instead of a
14771477
number of arguments. (Contributed by Greg Chapman.)
14781478

1479-
* A new method flag, :c:macro:`METH_COEXISTS`, allows a function defined in slots
1479+
* A new method flag, :c:macro:`METH_COEXIST`, allows a function defined in slots
14801480
to co-exist with a :c:type:`PyCFunction` having the same name. This can halve
14811481
the access time for a method such as :meth:`set.__contains__`. (Contributed by
14821482
Raymond Hettinger.)

‎Doc/whatsnew/2.6.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -3060,9 +3060,9 @@ Changes to Python's build process and to the C API include:
30603060

30613061
* Some macros were renamed in both 3.0 and 2.6 to make it clearer that
30623062
they are macros,
3063-
not functions. :c:macro:`Py_Size()` became :c:macro:`Py_SIZE()`,
3064-
:c:macro:`Py_Type()` became :c:macro:`Py_TYPE()`, and
3065-
:c:macro:`Py_Refcnt()` became :c:macro:`Py_REFCNT()`.
3063+
not functions. :c:macro:`!Py_Size()` became :c:macro:`Py_SIZE()`,
3064+
:c:macro:`!Py_Type()` became :c:macro:`Py_TYPE()`, and
3065+
:c:macro:`!Py_Refcnt()` became :c:macro:`Py_REFCNT()`.
30663066
The mixed-case macros are still available
30673067
in Python 2.6 for backward compatibility.
30683068
(:issue:`1629`)

‎Doc/whatsnew/2.7.rst

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -2287,10 +2287,10 @@ object, and then get the ``void *`` pointer, which will usually point
22872287
to an array of pointers to the module's various API functions.
22882288

22892289
There is an existing data type already used for this,
2290-
:c:type:`PyCObject`, but it doesn't provide type safety. Evil code
2290+
:c:type:`!PyCObject`, but it doesn't provide type safety. Evil code
22912291
written in pure Python could cause a segmentation fault by taking a
2292-
:c:type:`PyCObject` from module A and somehow substituting it for the
2293-
:c:type:`PyCObject` in module B. Capsules know their own name,
2292+
:c:type:`!PyCObject` from module A and somehow substituting it for the
2293+
:c:type:`!PyCObject` in module B. Capsules know their own name,
22942294
and getting the pointer requires providing the name:
22952295

22962296
.. code-block:: c
@@ -2310,10 +2310,10 @@ detect the mismatched name and return false. Refer to
23102310
:ref:`using-capsules` for more information on using these objects.
23112311

23122312
Python 2.7 now uses capsules internally to provide various
2313-
extension-module APIs, but the :c:func:`PyCObject_AsVoidPtr` was
2313+
extension-module APIs, but the :c:func:`!PyCObject_AsVoidPtr` was
23142314
modified to handle capsules, preserving compile-time compatibility
2315-
with the :c:type:`CObject` interface. Use of
2316-
:c:func:`PyCObject_AsVoidPtr` will signal a
2315+
with the :c:type:`!PyCObject` interface. Use of
2316+
:c:func:`!PyCObject_AsVoidPtr` will signal a
23172317
:exc:`PendingDeprecationWarning`, which is silent by default.
23182318

23192319
Implemented in Python 3.1 and backported to 2.7 by Larry Hastings;

‎Doc/whatsnew/3.0.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -875,7 +875,7 @@ to the C API.
875875
* Renamed the boolean conversion C-level slot and method:
876876
``nb_nonzero`` is now ``nb_bool``.
877877

878-
* Removed :c:macro:`METH_OLDARGS` and :c:macro:`WITH_CYCLE_GC` from the C API.
878+
* Removed :c:macro:`!METH_OLDARGS` and :c:macro:`!WITH_CYCLE_GC` from the C API.
879879

880880
.. ======================================================================
881881

‎Doc/whatsnew/3.1.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -510,7 +510,7 @@ Changes to Python's build process and to the C API include:
510510

511511
(Contributed by Mark Dickinson; :issue:`5914`.)
512512

513-
* Added :c:type:`PyCapsule` as a replacement for the :c:type:`PyCObject` API.
513+
* Added :c:type:`PyCapsule` as a replacement for the :c:type:`!PyCObject` API.
514514
The principal difference is that the new type has a well defined interface
515515
for passing typing safety information and a less complicated signature
516516
for calling a destructor. The old type had a problematic API and is now

‎Doc/whatsnew/3.2.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2658,7 +2658,7 @@ require changes to your code:
26582658
* "t#" format has been removed: use "s#" or "s*" instead
26592659
* "w" and "w#" formats has been removed: use "w*" instead
26602660

2661-
* The :c:type:`PyCObject` type, deprecated in 3.1, has been removed. To wrap
2661+
* The :c:type:`!PyCObject` type, deprecated in 3.1, has been removed. To wrap
26622662
opaque C pointers in Python objects, the :c:type:`PyCapsule` API should be used
26632663
instead; the new type has a well-defined interface for passing typing safety
26642664
information and a less complicated signature for calling a destructor.

0 commit comments

Comments
 (0)
0