Note that tp_clear and m_clear are not always called (GH-27581) (GH-27597)

(cherry picked from commit 10faada709)

Co-authored-by: Petr Viktorin <encukou@gmail.com>
This commit is contained in:
Miss Islington (bot) 2021-08-04 11:24:03 -07:00 committed by GitHub
parent bf9425be5d
commit 467c873e49
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 12 additions and 0 deletions

View file

@ -221,6 +221,12 @@ or request "multi-phase initialization" by returning the definition struct itsel
than 0 and the module state (as returned by :c:func:`PyModule_GetState`)
is ``NULL``.
Like :c:member:`PyTypeObject.tp_clear`, this function is not *always*
called before a module is deallocated. For example, when reference
counting is enough to determine that an object is no longer used,
the cyclic garbage collector is not involved and
:c:member:`~PyModuleDef.m_free` is called directly.
.. versionchanged:: 3.9
No longer called before the module state is allocated.

View file

@ -1294,6 +1294,12 @@ and :c:type:`PyType_Type` effectively act as defaults.)
so that *self* knows the contained object can no longer be used. The
:c:func:`Py_CLEAR` macro performs the operations in a safe order.
Note that :c:member:`~PyTypeObject.tp_clear` is not *always* called
before an instance is deallocated. For example, when reference counting
is enough to determine that an object is no longer used, the cyclic garbage
collector is not involved and :c:member:`~PyTypeObject.tp_dealloc` is
called directly.
Because the goal of :c:member:`~PyTypeObject.tp_clear` functions is to break reference cycles,
it's not necessary to clear contained objects like Python strings or Python
integers, which can't participate in reference cycles. On the other hand, it may