# 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 ""