# SOME DESCRIPTIVE TITLE. # Copyright (C) 2001 Python Software Foundation # This file is distributed under the same license as the Python package. # FIRST AUTHOR , YEAR. # # Translators: # python-doc bot, 2025 # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Python 3.15\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2026-08-13 14:51+0000\n" "PO-Revision-Date: 2025-09-16 00:00+0000\n" "Last-Translator: python-doc bot, 2025\n" "Language-Team: Polish (https://app.transifex.com/python-doc/teams/5390/pl/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Language: pl\n" "Plural-Forms: nplurals=4; plural=(n==1 ? 0 : (n%10>=2 && n%10<=4) && " "(n%100<12 || n%100>14) ? 1 : n!=1 && (n%10>=0 && n%10<=1) || (n%10>=5 && " "n%10<=9) || (n%100>=12 && n%100<=14) ? 2 : 3);\n" msgid "Object Life Cycle" msgstr "" 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 "" msgid "Life Events" msgstr "" 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 "" msgid "Diagram showing events in an object's life. Explained in detail below." msgstr "" msgid "Explanation:" msgstr "" msgid "When a new object is constructed by calling its type:" msgstr "" msgid ":c:member:`~PyTypeObject.tp_new` is called to create a new object." msgstr "" msgid "" ":c:member:`~PyTypeObject.tp_alloc` is directly called by :c:member:" "`~PyTypeObject.tp_new` to allocate the memory for the new object." msgstr "" 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 "" msgid "After :c:member:`!tp_init` completes, the object is ready to use." msgstr "" msgid "Some time after the last reference to an object is removed:" msgstr "" 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 "" 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 "" 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 "" 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 "" 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 "" 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 "" 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 "" 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 "" msgid "" "The garbage collector occasionally calls :c:member:`~PyTypeObject." "tp_traverse` to identify :term:`cyclic isolates `." msgstr "" 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 "" 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 "" 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 "" msgid "Cyclic Isolate Destruction" msgstr "" 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 "" 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 "" 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 "" 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 "" msgid "" "**All finalized:** All objects in a cyclic isolate are finalized before any " "of them are cleared." msgstr "" 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 "" 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 "" 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 "" 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 "" 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 "" msgid "To summarize the possible interactions:" msgstr "" msgid "" "A non-finalized object might have references to or from non-finalized and " "finalized objects, but not to or from cleared objects." msgstr "" msgid "" "A finalized object might have references to or from non-finalized, " "finalized, and cleared objects." msgstr "" msgid "" "A cleared object might have references to or from finalized and cleared " "objects, but not to or from non-finalized objects." msgstr "" 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 "" msgid "Functions" msgstr "Zadania" msgid "To allocate and free memory, see :ref:`allocating-objects`." msgstr "" 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 "" 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 "" msgid ":c:member:`~PyTypeObject.tp_dealloc` for example code." msgstr ""