# SOME DESCRIPTIVE TITLE. # Copyright (C) 2001 Python Software Foundation # This file is distributed under the same license as the Python package. # FIRST AUTHOR , 2025. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Python 3.14\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2025-10-11 20:40+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language: ko\n" "Language-Team: ko \n" "Plural-Forms: nplurals=1; plural=0;\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" "Generated-By: Babel 2.17.0\n" #: ../../c-api/lifecycle.rst:6 msgid "Object Life Cycle" msgstr "" #: ../../c-api/lifecycle.rst:8 msgid "" "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." msgstr "" #: ../../c-api/lifecycle.rst:15 msgid "Life Events" msgstr "" #: ../../c-api/lifecycle.rst:17 msgid "" "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*." msgstr "" #: ../../c-api/lifecycle.rst:55 ../../c-api/lifecycle.rst:62 msgid "Diagram showing events in an object's life. Explained in detail below." msgstr "" #: ../../c-api/lifecycle.rst:70 msgid "Explanation:" msgstr "" #: ../../c-api/lifecycle.rst:72 msgid "When a new object is constructed by calling its type:" msgstr "" #: ../../c-api/lifecycle.rst:74 msgid ":c:member:`~PyTypeObject.tp_new` is called to create a new object." msgstr "" #: ../../c-api/lifecycle.rst:75 msgid "" ":c:member:`~PyTypeObject.tp_alloc` is directly called by " ":c:member:`~PyTypeObject.tp_new` to allocate the memory for the new " "object." msgstr "" #: ../../c-api/lifecycle.rst:78 msgid "" ":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__`." msgstr "" #: ../../c-api/lifecycle.rst:83 msgid "After :c:member:`!tp_init` completes, the object is ready to use." msgstr "" #: ../../c-api/lifecycle.rst:84 msgid "Some time after the last reference to an object is removed:" msgstr "" #: ../../c-api/lifecycle.rst:86 msgid "" "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." msgstr "" #: ../../c-api/lifecycle.rst:92 msgid "" "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." msgstr "" #: ../../c-api/lifecycle.rst:96 msgid "" ":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." msgstr "" #: ../../c-api/lifecycle.rst:100 msgid "" "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." msgstr "" #: ../../c-api/lifecycle.rst:105 msgid "" "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." msgstr "" #: ../../c-api/lifecycle.rst:118 msgid "" ":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." msgstr "" #: ../../c-api/lifecycle.rst:125 msgid "" "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`." msgstr "" #: ../../c-api/lifecycle.rst:132 msgid "" "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:" msgstr "" #: ../../c-api/lifecycle.rst:136 msgid "" "The garbage collector occasionally calls " ":c:member:`~PyTypeObject.tp_traverse` to identify :term:`cyclic isolates " "`." msgstr "" #: ../../c-api/lifecycle.rst:139 msgid "" "When the garbage collector discovers a :term:`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." msgstr "" #: ../../c-api/lifecycle.rst:144 msgid "" ":c:member:`~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)." msgstr "" #: ../../c-api/lifecycle.rst:149 msgid "" "When the garbage collector discovers a :term:`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." msgstr "" #: ../../c-api/lifecycle.rst:158 msgid "Cyclic Isolate Destruction" msgstr "" #: ../../c-api/lifecycle.rst:160 msgid "" "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`)." msgstr "" #: ../../c-api/lifecycle.rst:168 msgid "" "**Reachable** (not yet a cyclic isolate): All objects are in their " "normal, reachable state. A reference cycle could exist, but an external " "reference means the objects are not yet isolated." msgstr "" #: ../../c-api/lifecycle.rst:171 msgid "" "**Unreachable but consistent:** The final reference from outside the " "cyclic group of objects has been removed, causing the objects to become " "isolated (thus a cyclic isolate is born). None of the group's objects " "have been finalized or cleared yet. The cyclic isolate remains at this " "stage until some future run of the garbage collector (not necessarily the" " next run because the next run might not scan every object)." msgstr "" #: ../../c-api/lifecycle.rst:177 msgid "" "**Mix of finalized and not finalized:** Objects in a cyclic isolate are " "finalized one at a time, which means that there is a period of time when " "the cyclic isolate is composed of a mix of finalized and non-finalized " "objects. Finalization order is unspecified, so it can appear random. A " "finalized object must behave in a sane manner when non-finalized objects " "interact with it, and a non-finalized object must be able to tolerate the" " finalization of an arbitrary subset of its referents." msgstr "" #: ../../c-api/lifecycle.rst:184 msgid "" "**All finalized:** All objects in a cyclic isolate are finalized before " "any of them are cleared." msgstr "" #: ../../c-api/lifecycle.rst:186 msgid "" "**Mix of finalized and cleared:** The objects can be cleared serially or " "concurrently (but with the :term:`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\"." msgstr "" #: ../../c-api/lifecycle.rst:190 msgid "" "**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." msgstr "" #: ../../c-api/lifecycle.rst:197 msgid "" "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." msgstr "" #: ../../c-api/lifecycle.rst:206 msgid "" "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`." msgstr "" #: ../../c-api/lifecycle.rst:214 msgid "" "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." msgstr "" #: ../../c-api/lifecycle.rst:223 msgid "To summarize the possible interactions:" msgstr "" #: ../../c-api/lifecycle.rst:225 msgid "" "A non-finalized object might have references to or from non-finalized and" " finalized objects, but not to or from cleared objects." msgstr "" #: ../../c-api/lifecycle.rst:227 msgid "" "A finalized object might have references to or from non-finalized, " "finalized, and cleared objects." msgstr "" #: ../../c-api/lifecycle.rst:229 msgid "" "A cleared object might have references to or from finalized and cleared " "objects, but not to or from non-finalized objects." msgstr "" #: ../../c-api/lifecycle.rst:232 msgid "" "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." msgstr "" #: ../../c-api/lifecycle.rst:244 msgid "Functions" msgstr "" #: ../../c-api/lifecycle.rst:246 msgid "To allocate and free memory, see :ref:`allocating-objects`." msgstr "" #: ../../c-api/lifecycle.rst:251 msgid "" "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." msgstr "" #: ../../c-api/lifecycle.rst:262 msgid "" "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." msgstr "" #: ../../c-api/lifecycle.rst:271 msgid ":c:member:`~PyTypeObject.tp_dealloc` for example code." msgstr ""