iframe-proxy | Sunbelt Computer Software

320 lines (275 loc) · 13.3 KB
# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001 Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
# Translators:
# python-doc bot, 2025
"Project-Id-Version: Python 3.15\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2026-06-21 15:47+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"
"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."
msgid "Life Events"
"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*."
msgid "Diagram showing events in an object's life.  Explained in detail below."
msgid "Explanation:"
msgid "When a new object is constructed by calling its type:"
msgid ":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__`."
msgid "After :c:member:`!tp_init` completes, the object is ready to use."
msgid "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:"
"The garbage collector occasionally calls :c:member:`~PyTypeObject."
"tp_traverse` to identify :term:`cyclic isolates <cyclic isolate>`."
"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."
":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)."
"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."
msgid "Cyclic Isolate Destruction"
"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`)."
"**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."
"**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)."
"**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."
"**All finalized:** All objects in a cyclic isolate are finalized before any "
"of them are cleared."
"**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\"."
"**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."
msgid "To summarize the possible interactions:"
"A non-finalized object might have references to or from non-finalized and "
"finalized objects, but not to or from cleared objects."
"A finalized object might have references to or from non-finalized, "
"finalized, and cleared objects."
"A cleared object might have references to or from finalized and cleared "
"objects, but not to or from non-finalized objects."
"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."
msgid "Functions"
msgstr "Zadania"
msgid "To allocate and free memory, see :ref:`allocating-objects`."
"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."
"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."
msgid ":c:member:`~PyTypeObject.tp_dealloc` for example code."
Sunbelt Computer Software

PL/B Language Development and Support

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

Uh oh!

FilesExpand file tree

lifecycle.po

Latest commit

History

lifecycle.po

File metadata and controls
