Doc/c-api/lifecycle.rst
.. highlight:: c
.. _life-cycle:
This section explains how a type's slots relate to each other throughout the
life of an object. It is not intended to be a complete canonical reference for
the slots; instead, refer to the slot-specific documentation in
:ref:type-structs for details about a particular slot.
The figure below illustrates the order of events that can occur throughout an object's life. An arrow from A to B indicates that event B can occur after event A has occurred, with the arrow's label indicating the condition that must be true for B to occur after A.
.. only:: html and not epub
.. raw:: html
<style type="text/css">
.. raw:: html :file: lifecycle.dot.css
.. raw:: html
</style>
.. raw:: html :file: lifecycle.dot.svg
.. raw:: html
<script>
(() => {
const g = document.getElementById('life_events_graph');
const title = g.querySelector(':scope > title');
title.id = 'life-events-graph-title';
const svg = g.closest('svg');
svg.role = 'img';
svg.setAttribute('aria-describedby',
'life-events-graph-description');
svg.setAttribute('aria-labelledby', 'life-events-graph-title');
})();
</script>
.. only:: epub or not (html or latex)
.. image:: lifecycle.dot.svg :align: center :class: invert-in-dark-mode :alt: Diagram showing events in an object's life. Explained in detail below.
.. only:: latex
.. image:: lifecycle.dot.pdf :align: center :class: invert-in-dark-mode :alt: Diagram showing events in an object's life. Explained in detail below.
.. container:: :name: life-events-graph-description
Explanation:
When a new object is constructed by calling its type:
#. :c:member:~PyTypeObject.tp_new is called to create a new object.
#. :c:member:~PyTypeObject.tp_alloc is directly called by
:c:member:~PyTypeObject.tp_new to allocate the memory for the new
object.
#. :c:member:~PyTypeObject.tp_init initializes the newly created object.
:c:member:!tp_init can be called again to re-initialize an object, if
desired. The :c:member:!tp_init call can also be skipped entirely,
for example by Python code calling :py:meth:~object.__new__.
After :c:member:!tp_init completes, the object is ready to use.
Some time after the last reference to an object is removed:
#. If an object is not marked as finalized, it might be finalized by
marking it as finalized and calling its
:c:member:~PyTypeObject.tp_finalize function. Python does
not finalize an object when the last reference to it is deleted; use
:c:func:PyObject_CallFinalizerFromDealloc to ensure that
:c:member:~PyTypeObject.tp_finalize is always called.
#. If the object is marked as finalized,
:c:member:~PyTypeObject.tp_clear might be called by the garbage collector
to clear references held by the object. It is not called when the
object's reference count reaches zero.
#. :c:member:~PyTypeObject.tp_dealloc is called to destroy the object.
To avoid code duplication, :c:member:~PyTypeObject.tp_dealloc typically
calls into :c:member:~PyTypeObject.tp_clear to free up the object's
references.
#. When :c:member:~PyTypeObject.tp_dealloc finishes object destruction,
it directly calls :c:member:~PyTypeObject.tp_free (usually set to
:c:func:PyObject_Free or :c:func:PyObject_GC_Del automatically as
appropriate for the type) to deallocate the memory.
The :c:member:~PyTypeObject.tp_finalize function is permitted to add a
reference to the object if desired. If it does, the object is
resurrected, preventing its pending destruction. (Only
:c:member:!tp_finalize is allowed to resurrect an object;
:c:member:~PyTypeObject.tp_clear and
:c:member:~PyTypeObject.tp_dealloc cannot without calling into
:c:member:!tp_finalize.) Resurrecting an object may
or may not cause the object's finalized mark to be removed. Currently,
Python does not remove the finalized mark from a resurrected object if
it supports garbage collection (i.e., the :c:macro:Py_TPFLAGS_HAVE_GC
flag is set) but does remove the mark if the object does not support
garbage collection; either or both of these behaviors may change in the
future.
:c:member:~PyTypeObject.tp_dealloc can optionally call
:c:member:~PyTypeObject.tp_finalize via
:c:func:PyObject_CallFinalizerFromDealloc if it wishes to reuse that
code to help with object destruction. This is recommended because it
guarantees that :c:member:!tp_finalize is always called before
destruction. See the :c:member:~PyTypeObject.tp_dealloc documentation
for example code.
If the object is a member of a :term:cyclic isolate and either
:c:member:~PyTypeObject.tp_clear fails to break the reference cycle or
the cyclic isolate is not detected (perhaps :func:gc.disable was called,
or the :c:macro:Py_TPFLAGS_HAVE_GC flag was erroneously omitted in one
of the involved types), the objects remain indefinitely uncollectable
(they "leak"). See :data:gc.garbage.
If the object is marked as supporting garbage collection (the
:c:macro:Py_TPFLAGS_HAVE_GC flag is set in
:c:member:~PyTypeObject.tp_flags), the following events are also possible:
~PyTypeObject.tp_traverse to identify :term:cyclic isolates <cyclic isolate>.cyclic isolate, it
finalizes one of the objects in the group by marking it as finalized and
calling its :c:member:~PyTypeObject.tp_finalize function, if it has one.
This repeats until the cyclic isolate doesn't exist or all of the objects
have been finalized.~PyTypeObject.tp_finalize is permitted to resurrect the object
by adding a reference from outside the :term:cyclic isolate. The new
reference causes the group of objects to no longer form a cyclic isolate
(the reference cycle may still exist, but if it does the objects are no
longer isolated).cyclic isolate and all of
the objects in the group have already been marked as finalized, the
garbage collector clears one or more of the uncleared objects in the group
(possibly concurrently) by calling each's
:c:member:~PyTypeObject.tp_clear function. This repeats as long as the
cyclic isolate still exists and not all of the objects have been cleared.Listed below are the stages of life of a hypothetical :term:cyclic isolate
that continues to exist after each member object is finalized or cleared. It
is a memory leak if a cyclic isolate progresses through all of these stages; it should
vanish once all objects are cleared, if not sooner. A cyclic isolate can
vanish either because the reference cycle is broken or because the objects are
no longer isolated due to finalizer resurrection (see
:c:member:~PyTypeObject.tp_finalize).
GIL held); either way, some will finish
before others. A finalized object must be able to tolerate the clearing of
a subset of its referents. :pep:442 calls this stage "cyclic trash".
#. Leaked: If a cyclic isolate still exists after all objects in the group
have been finalized and cleared, then the objects remain indefinitely
uncollectable (see :data:gc.garbage). It is a bug if a cyclic isolate
reaches this stage---it means the :c:member:~PyTypeObject.tp_clear methods
of the participating objects have failed to break the reference cycle as
required.If :c:member:~PyTypeObject.tp_clear did not exist, then Python would have no
way to safely break a reference cycle. Simply destroying an object in a cyclic
isolate would result in a dangling pointer, triggering undefined behavior when
an object referencing the destroyed object is itself destroyed. The clearing
step makes object destruction a two-phase process: first
:c:member:~PyTypeObject.tp_clear is called to partially destroy the objects
enough to detangle them from each other, then
:c:member:~PyTypeObject.tp_dealloc is called to complete the destruction.
Unlike clearing, finalization is not a phase of destruction. A finalized
object must still behave properly by continuing to fulfill its design
contracts. An object's finalizer is allowed to execute arbitrary Python code,
and is even allowed to prevent the impending destruction by adding a reference.
The finalizer is only related to destruction by call order---if it runs, it runs
before destruction, which starts with :c:member:~PyTypeObject.tp_clear (if
called) and concludes with :c:member:~PyTypeObject.tp_dealloc.
The finalization step is not necessary to safely reclaim the objects in a cyclic isolate, but its existence makes it easier to design types that behave in a sane manner when objects are cleared. Clearing an object might necessarily leave it in a broken, partially destroyed state---it might be unsafe to call any of the cleared object's methods or access any of its attributes. With finalization, only finalized objects can possibly interact with cleared objects; non-finalized objects are guaranteed to interact with only non-cleared (but potentially finalized) objects.
To summarize the possible interactions:
Without any reference cycles, an object can be simply destroyed once its last
reference is deleted; the finalization and clearing steps are not necessary to
safely reclaim unused objects. However, it can be useful to automatically call
:c:member:~PyTypeObject.tp_finalize and :c:member:~PyTypeObject.tp_clear
before destruction anyway because type design is simplified when all objects
always experience the same series of events regardless of whether they
participated in a cyclic isolate. Python currently only calls
:c:member:~PyTypeObject.tp_finalize and :c:member:~PyTypeObject.tp_clear as
needed to destroy a cyclic isolate; this may change in a future version.
To allocate and free memory, see :ref:allocating-objects.
.. c:function:: void PyObject_CallFinalizer(PyObject *op)
Finalizes the object as described in :c:member:~PyTypeObject.tp_finalize.
Call this function (or :c:func:PyObject_CallFinalizerFromDealloc) instead
of calling :c:member:~PyTypeObject.tp_finalize directly because this
function may deduplicate multiple calls to :c:member:!tp_finalize.
Currently, calls are only deduplicated if the type supports garbage
collection (i.e., the :c:macro:Py_TPFLAGS_HAVE_GC flag is set); this may
change in the future.
.. versionadded:: 3.4
.. c:function:: int PyObject_CallFinalizerFromDealloc(PyObject *op)
Same as :c:func:PyObject_CallFinalizer but meant to be called at the
beginning of the object's destructor (:c:member:~PyTypeObject.tp_dealloc).
There must not be any references to the object. If the object's finalizer
resurrects the object, this function returns -1; no further destruction
should happen. Otherwise, this function returns 0 and destruction can
continue normally.
.. versionadded:: 3.4
.. seealso::
:c:member:`~PyTypeObject.tp_dealloc` for example code.