diff options
| author | Serhiy Storchaka <storchaka@gmail.com> | 2023-07-28 08:31:49 (GMT) |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-07-28 08:31:49 (GMT) |
| commit | d9392c0c0aeedd4d23027ecf20e14af4c227435a (patch) | |
| tree | f3829db506957c8fa53a4aee97350fb3a43b16e8 /Doc/whatsnew | |
| parent | 32e17d4a3c1da2a8ff082b5cb4f3cd13688a95a1 (diff) | |
| download | cpython-d9392c0c0aeedd4d23027ecf20e14af4c227435a.zip cpython-d9392c0c0aeedd4d23027ecf20e14af4c227435a.tar.gz cpython-d9392c0c0aeedd4d23027ecf20e14af4c227435a.tar.bz2 | |
[3.11] gh-107298: Fix yet more Sphinx warnings in the C API doc (GH-107345) (GH-107381)
(cherry picked from commit 983305268e2291b0a7835621b81bf40cba7c27f3)
Diffstat (limited to 'Doc/whatsnew')
| -rw-r--r-- | Doc/whatsnew/2.5.rst | 4 | ||||
| -rw-r--r-- | Doc/whatsnew/3.8.rst | 2 |
2 files changed, 3 insertions, 3 deletions
diff --git a/Doc/whatsnew/2.5.rst b/Doc/whatsnew/2.5.rst index 162d2c3..a15eefc 100644 --- a/Doc/whatsnew/2.5.rst +++ b/Doc/whatsnew/2.5.rst @@ -2151,8 +2151,8 @@ Changes to Python's build process and to the C API include: Previously these different families all reduced to the platform's :c:func:`malloc` and :c:func:`free` functions. This meant it didn't matter if - you got things wrong and allocated memory with the :c:func:`PyMem` function but - freed it with the :c:func:`PyObject` function. With 2.5's changes to obmalloc, + you got things wrong and allocated memory with the ``PyMem`` function but + freed it with the ``PyObject`` function. With 2.5's changes to obmalloc, these families now do different things and mismatches will probably result in a segfault. You should carefully test your C extension modules with Python 2.5. diff --git a/Doc/whatsnew/3.8.rst b/Doc/whatsnew/3.8.rst index 7bfff94..b3a6f11 100644 --- a/Doc/whatsnew/3.8.rst +++ b/Doc/whatsnew/3.8.rst @@ -1847,7 +1847,7 @@ Changes in Python behavior finalizing, making them consistent with :c:func:`PyEval_RestoreThread`, :c:func:`Py_END_ALLOW_THREADS`, and :c:func:`PyGILState_Ensure`. If this behavior is not desired, guard the call by checking :c:func:`_Py_IsFinalizing` - or :c:func:`sys.is_finalizing`. + or :func:`sys.is_finalizing`. (Contributed by Joannah Nanjekye in :issue:`36475`.) |