mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-08-15 22:30:42 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 10

[3.12] Doc: C API: Move tp_dealloc paragraph to tp_dealloc section (GH-125737) (#125799)

Browse source 
Doc: C API: Move `tp_dealloc` paragraph to `tp_dealloc` section (GH-125737)

It looks like commit 43cf44ddcc
(gh-31501) accidentally moved the paragraph to the `tp_finalize`
section when the intent was to move it to the `tp_dealloc` section
(according to the commit message).

(cherry picked from commit d880c83ff7)

Co-authored-by: Richard Hansen <rhansen@rhansen.org>
This commit is contained in:
Miss Islington (bot) 2024-10-21 18:55:11 +02:00 • committed by GitHub
parent 2746ec4ce2
commit c3e705fbe5
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 13 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

24
Doc/c-api/typeobj.rst
View file

@ -704,6 +704,19 @@ and :c:data:`PyType_Type` effectively act as defaults.)
Py_DECREF(tp);
}
.. warning::
In a garbage collected Python, :c:member:`!tp_dealloc` may be called from
any Python thread, not just the thread which created the object (if the
object becomes part of a refcount cycle, that cycle might be collected by
a garbage collection on any thread). This is not a problem for Python
API calls, since the thread on which :c:member:`!tp_dealloc` is called
will own the Global Interpreter Lock (GIL). However, if the object being
destroyed in turn destroys objects from some other C or C++ library, care
should be taken to ensure that destroying those objects on the thread
which called :c:member:`!tp_dealloc` will not violate any assumptions of
the library.
**Inheritance:**
@ -2101,17 +2114,6 @@ and :c:data:`PyType_Type` effectively act as defaults.)
PyErr_Restore(error_type, error_value, error_traceback);
}
Also, note that, in a garbage collected Python,
:c:member:`~PyTypeObject.tp_dealloc` may be called from
any Python thread, not just the thread which created the object (if the object
becomes part of a refcount cycle, that cycle might be collected by a garbage
collection on any thread). This is not a problem for Python API calls, since
the thread on which tp_dealloc is called will own the Global Interpreter Lock
(GIL). However, if the object being destroyed in turn destroys objects from some
other C or C++ library, care should be taken to ensure that destroying those
objects on the thread which called tp_dealloc will not violate any assumptions
of the library.
**Inheritance:**
This field is inherited by subtypes.