|
| 1 | +# SOME DESCRIPTIVE TITLE. |
| 2 | +# Copyright (C) 2001 Python Software Foundation |
| 3 | +# This file is distributed under the same license as the Python package. |
| 4 | +# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. |
| 5 | +# |
| 6 | +# Translators: |
| 7 | +# tomo, 2025 |
| 8 | +# |
| 9 | +#,fuzzy |
| 10 | +msgid "" |
| 11 | +msgstr "" |
| 12 | +"Project-Id-Version:Python 3.14\n" |
| 13 | +"Report-Msgid-Bugs-To:\n" |
| 14 | +"POT-Creation-Date:2025-05-23 14:20+0000\n" |
| 15 | +"PO-Revision-Date:2025-05-23 14:21+0000\n" |
| 16 | +"Last-Translator:tomo, 2025\n" |
| 17 | +"Language-Team:Japanese (https://app.transifex.com/python-doc/teams/5390/" |
| 18 | +"ja/)\n" |
| 19 | +"MIME-Version:1.0\n" |
| 20 | +"Content-Type:text/plain; charset=UTF-8\n" |
| 21 | +"Content-Transfer-Encoding:8bit\n" |
| 22 | +"Language:ja\n" |
| 23 | +"Plural-Forms:nplurals=1; plural=0;\n" |
| 24 | + |
| 25 | +#:../../c-api/lifecycle.rst:6 |
| 26 | +msgid"Object Life Cycle" |
| 27 | +msgstr"" |
| 28 | + |
| 29 | +#:../../c-api/lifecycle.rst:8 |
| 30 | +msgid"" |
| 31 | +"This section explains how a type's slots relate to each other throughout the " |
| 32 | +"life of an object. It is not intended to be a complete canonical reference " |
| 33 | +"for the slots; instead, refer to the slot-specific documentation in :ref:" |
| 34 | +"`type-structs` for details about a particular slot." |
| 35 | +msgstr"" |
| 36 | + |
| 37 | +#:../../c-api/lifecycle.rst:15 |
| 38 | +msgid"Life Events" |
| 39 | +msgstr"" |
| 40 | + |
| 41 | +#:../../c-api/lifecycle.rst:17 |
| 42 | +msgid"" |
| 43 | +"The figure below illustrates the order of events that can occur throughout " |
| 44 | +"an object's life. An arrow from *A* to *B* indicates that event *B* can " |
| 45 | +"occur after event *A* has occurred, with the arrow's label indicating the " |
| 46 | +"condition that must be true for *B* to occur after *A*." |
| 47 | +msgstr"" |
| 48 | + |
| 49 | +#:../../c-api/lifecycle.rst:55../../c-api/lifecycle.rst:63 |
| 50 | +msgid"" |
| 51 | +"Diagram showing events in an object's life. Explained in detail\n" |
| 52 | +"below." |
| 53 | +msgstr"" |
| 54 | + |
| 55 | +#:../../c-api/lifecycle.rst:72 |
| 56 | +msgid"Explanation:" |
| 57 | +msgstr"" |
| 58 | + |
| 59 | +#:../../c-api/lifecycle.rst:74 |
| 60 | +msgid"When a new object is constructed by calling its type:" |
| 61 | +msgstr"" |
| 62 | + |
| 63 | +#:../../c-api/lifecycle.rst:76 |
| 64 | +msgid":c:member:`~PyTypeObject.tp_new` is called to create a new object." |
| 65 | +msgstr"" |
| 66 | + |
| 67 | +#:../../c-api/lifecycle.rst:77 |
| 68 | +msgid"" |
| 69 | +":c:member:`~PyTypeObject.tp_alloc` is directly called by :c:member:" |
| 70 | +"`~PyTypeObject.tp_new` to allocate the memory for the new object." |
| 71 | +msgstr"" |
| 72 | + |
| 73 | +#:../../c-api/lifecycle.rst:80 |
| 74 | +msgid"" |
| 75 | +":c:member:`~PyTypeObject.tp_init` initializes the newly created object. :c:" |
| 76 | +"member:`!tp_init` can be called again to re-initialize an object, if " |
| 77 | +"desired. The :c:member:`!tp_init` call can also be skipped entirely, for " |
| 78 | +"example by Python code calling :py:meth:`~object.__new__`." |
| 79 | +msgstr"" |
| 80 | + |
| 81 | +#:../../c-api/lifecycle.rst:85 |
| 82 | +msgid"After :c:member:`!tp_init` completes, the object is ready to use." |
| 83 | +msgstr"" |
| 84 | + |
| 85 | +#:../../c-api/lifecycle.rst:86 |
| 86 | +msgid"Some time after the last reference to an object is removed:" |
| 87 | +msgstr"" |
| 88 | + |
| 89 | +#:../../c-api/lifecycle.rst:88 |
| 90 | +msgid"" |
| 91 | +"If an object is not marked as *finalized*, it might be finalized by marking " |
| 92 | +"it as *finalized* and calling its :c:member:`~PyTypeObject.tp_finalize` " |
| 93 | +"function. Python does *not* finalize an object when the last reference to " |
| 94 | +"it is deleted; use :c:func:`PyObject_CallFinalizerFromDealloc` to ensure " |
| 95 | +"that :c:member:`~PyTypeObject.tp_finalize` is always called." |
| 96 | +msgstr"" |
| 97 | + |
| 98 | +#:../../c-api/lifecycle.rst:94 |
| 99 | +msgid"" |
| 100 | +"If the object is marked as finalized, :c:member:`~PyTypeObject.tp_clear` " |
| 101 | +"might be called by the garbage collector to clear references held by the " |
| 102 | +"object. It is *not* called when the object's reference count reaches zero." |
| 103 | +msgstr"" |
| 104 | + |
| 105 | +#:../../c-api/lifecycle.rst:98 |
| 106 | +msgid"" |
| 107 | +":c:member:`~PyTypeObject.tp_dealloc` is called to destroy the object. To " |
| 108 | +"avoid code duplication, :c:member:`~PyTypeObject.tp_dealloc` typically calls " |
| 109 | +"into :c:member:`~PyTypeObject.tp_clear` to free up the object's references." |
| 110 | +msgstr"" |
| 111 | + |
| 112 | +#:../../c-api/lifecycle.rst:102 |
| 113 | +msgid"" |
| 114 | +"When :c:member:`~PyTypeObject.tp_dealloc` finishes object destruction, it " |
| 115 | +"directly calls :c:member:`~PyTypeObject.tp_free` (usually set to :c:func:" |
| 116 | +"`PyObject_Free` or :c:func:`PyObject_GC_Del` automatically as appropriate " |
| 117 | +"for the type) to deallocate the memory." |
| 118 | +msgstr"" |
| 119 | + |
| 120 | +#:../../c-api/lifecycle.rst:107 |
| 121 | +msgid"" |
| 122 | +"The :c:member:`~PyTypeObject.tp_finalize` function is permitted to add a " |
| 123 | +"reference to the object if desired. If it does, the object is " |
| 124 | +"*resurrected*, preventing its pending destruction. (Only :c:member:`!" |
| 125 | +"tp_finalize` is allowed to resurrect an object; :c:member:`~PyTypeObject." |
| 126 | +"tp_clear` and :c:member:`~PyTypeObject.tp_dealloc` cannot without calling " |
| 127 | +"into :c:member:`!tp_finalize`.) Resurrecting an object may or may not cause " |
| 128 | +"the object's *finalized* mark to be removed. Currently, Python does not " |
| 129 | +"remove the *finalized* mark from a resurrected object if it supports garbage " |
| 130 | +"collection (i.e., the :c:macro:`Py_TPFLAGS_HAVE_GC` flag is set) but does " |
| 131 | +"remove the mark if the object does not support garbage collection; either or " |
| 132 | +"both of these behaviors may change in the future." |
| 133 | +msgstr"" |
| 134 | + |
| 135 | +#:../../c-api/lifecycle.rst:120 |
| 136 | +msgid"" |
| 137 | +":c:member:`~PyTypeObject.tp_dealloc` can optionally call :c:member:" |
| 138 | +"`~PyTypeObject.tp_finalize` via :c:func:`PyObject_CallFinalizerFromDealloc` " |
| 139 | +"if it wishes to reuse that code to help with object destruction. This is " |
| 140 | +"recommended because it guarantees that :c:member:`!tp_finalize` is always " |
| 141 | +"called before destruction. See the :c:member:`~PyTypeObject.tp_dealloc` " |
| 142 | +"documentation for example code." |
| 143 | +msgstr"" |
| 144 | + |
| 145 | +#:../../c-api/lifecycle.rst:127 |
| 146 | +msgid"" |
| 147 | +"If the object is a member of a :term:`cyclic isolate` and either :c:member:" |
| 148 | +"`~PyTypeObject.tp_clear` fails to break the reference cycle or the cyclic " |
| 149 | +"isolate is not detected (perhaps :func:`gc.disable` was called, or the :c:" |
| 150 | +"macro:`Py_TPFLAGS_HAVE_GC` flag was erroneously omitted in one of the " |
| 151 | +"involved types), the objects remain indefinitely uncollectable (they " |
| 152 | +"\"leak\"). See :data:`gc.garbage`." |
| 153 | +msgstr"" |
| 154 | + |
| 155 | +#:../../c-api/lifecycle.rst:134 |
| 156 | +msgid"" |
| 157 | +"If the object is marked as supporting garbage collection (the :c:macro:" |
| 158 | +"`Py_TPFLAGS_HAVE_GC` flag is set in :c:member:`~PyTypeObject.tp_flags`), the " |
| 159 | +"following events are also possible:" |
| 160 | +msgstr"" |
| 161 | + |
| 162 | +#:../../c-api/lifecycle.rst:138 |
| 163 | +msgid"" |
| 164 | +"The garbage collector occasionally calls :c:member:`~PyTypeObject." |
| 165 | +"tp_traverse` to identify :term:`cyclic isolates <cyclic isolate>`." |
| 166 | +msgstr"" |
| 167 | + |
| 168 | +#:../../c-api/lifecycle.rst:141 |
| 169 | +msgid"" |
| 170 | +"When the garbage collector discovers a :term:`cyclic isolate`, it finalizes " |
| 171 | +"one of the objects in the group by marking it as *finalized* and calling " |
| 172 | +"its :c:member:`~PyTypeObject.tp_finalize` function, if it has one. This " |
| 173 | +"repeats until the cyclic isolate doesn't exist or all of the objects have " |
| 174 | +"been finalized." |
| 175 | +msgstr"" |
| 176 | + |
| 177 | +#:../../c-api/lifecycle.rst:146 |
| 178 | +msgid"" |
| 179 | +":c:member:`~PyTypeObject.tp_finalize` is permitted to resurrect the object " |
| 180 | +"by adding a reference from outside the :term:`cyclic isolate`. The new " |
| 181 | +"reference causes the group of objects to no longer form a cyclic isolate " |
| 182 | +"(the reference cycle may still exist, but if it does the objects are no " |
| 183 | +"longer isolated)." |
| 184 | +msgstr"" |
| 185 | + |
| 186 | +#:../../c-api/lifecycle.rst:151 |
| 187 | +msgid"" |
| 188 | +"When the garbage collector discovers a :term:`cyclic isolate` and all of the " |
| 189 | +"objects in the group have already been marked as *finalized*, the garbage " |
| 190 | +"collector clears one or more of the uncleared objects in the group (possibly " |
| 191 | +"concurrently) by calling each's :c:member:`~PyTypeObject.tp_clear` " |
| 192 | +"function. This repeats as long as the cyclic isolate still exists and not " |
| 193 | +"all of the objects have been cleared." |
| 194 | +msgstr"" |
| 195 | + |
| 196 | +#:../../c-api/lifecycle.rst:160 |
| 197 | +msgid"Cyclic Isolate Destruction" |
| 198 | +msgstr"" |
| 199 | + |
| 200 | +#:../../c-api/lifecycle.rst:162 |
| 201 | +msgid"" |
| 202 | +"Listed below are the stages of life of a hypothetical :term:`cyclic isolate` " |
| 203 | +"that continues to exist after each member object is finalized or cleared. " |
| 204 | +"It is a memory leak if a cyclic isolate progresses through all of these " |
| 205 | +"stages; it should vanish once all objects are cleared, if not sooner. A " |
| 206 | +"cyclic isolate can vanish either because the reference cycle is broken or " |
| 207 | +"because the objects are no longer isolated due to finalizer resurrection " |
| 208 | +"(see :c:member:`~PyTypeObject.tp_finalize`)." |
| 209 | +msgstr"" |
| 210 | + |
| 211 | +#:../../c-api/lifecycle.rst:170 |
| 212 | +msgid"" |
| 213 | +"**Reachable** (not yet a cyclic isolate): All objects are in their normal, " |
| 214 | +"reachable state. A reference cycle could exist, but an external reference " |
| 215 | +"means the objects are not yet isolated." |
| 216 | +msgstr"" |
| 217 | + |
| 218 | +#:../../c-api/lifecycle.rst:173 |
| 219 | +msgid"" |
| 220 | +"**Unreachable but consistent:** The final reference from outside the cyclic " |
| 221 | +"group of objects has been removed, causing the objects to become isolated " |
| 222 | +"(thus a cyclic isolate is born). None of the group's objects have been " |
| 223 | +"finalized or cleared yet. The cyclic isolate remains at this stage until " |
| 224 | +"some future run of the garbage collector (not necessarily the next run " |
| 225 | +"because the next run might not scan every object)." |
| 226 | +msgstr"" |
| 227 | + |
| 228 | +#:../../c-api/lifecycle.rst:179 |
| 229 | +msgid"" |
| 230 | +"**Mix of finalized and not finalized:** Objects in a cyclic isolate are " |
| 231 | +"finalized one at a time, which means that there is a period of time when the " |
| 232 | +"cyclic isolate is composed of a mix of finalized and non-finalized objects. " |
| 233 | +"Finalization order is unspecified, so it can appear random. A finalized " |
| 234 | +"object must behave in a sane manner when non-finalized objects interact with " |
| 235 | +"it, and a non-finalized object must be able to tolerate the finalization of " |
| 236 | +"an arbitrary subset of its referents." |
| 237 | +msgstr"" |
| 238 | + |
| 239 | +#:../../c-api/lifecycle.rst:186 |
| 240 | +msgid"" |
| 241 | +"**All finalized:** All objects in a cyclic isolate are finalized before any " |
| 242 | +"of them are cleared." |
| 243 | +msgstr"" |
| 244 | + |
| 245 | +#:../../c-api/lifecycle.rst:188 |
| 246 | +msgid"" |
| 247 | +"**Mix of finalized and cleared:** The objects can be cleared serially or " |
| 248 | +"concurrently (but with the :term:`GIL` held); either way, some will finish " |
| 249 | +"before others. A finalized object must be able to tolerate the clearing of " |
| 250 | +"a subset of its referents. :pep:`442` calls this stage\"cyclic trash\"." |
| 251 | +msgstr"" |
| 252 | + |
| 253 | +#:../../c-api/lifecycle.rst:192 |
| 254 | +msgid"" |
| 255 | +"**Leaked:** If a cyclic isolate still exists after all objects in the group " |
| 256 | +"have been finalized and cleared, then the objects remain indefinitely " |
| 257 | +"uncollectable (see :data:`gc.garbage`). It is a bug if a cyclic isolate " |
| 258 | +"reaches this stage---it means the :c:member:`~PyTypeObject.tp_clear` methods " |
| 259 | +"of the participating objects have failed to break the reference cycle as " |
| 260 | +"required." |
| 261 | +msgstr"" |
| 262 | + |
| 263 | +#:../../c-api/lifecycle.rst:199 |
| 264 | +msgid"" |
| 265 | +"If :c:member:`~PyTypeObject.tp_clear` did not exist, then Python would have " |
| 266 | +"no way to safely break a reference cycle. Simply destroying an object in a " |
| 267 | +"cyclic isolate would result in a dangling pointer, triggering undefined " |
| 268 | +"behavior when an object referencing the destroyed object is itself " |
| 269 | +"destroyed. The clearing step makes object destruction a two-phase process: " |
| 270 | +"first :c:member:`~PyTypeObject.tp_clear` is called to partially destroy the " |
| 271 | +"objects enough to detangle them from each other, then :c:member:" |
| 272 | +"`~PyTypeObject.tp_dealloc` is called to complete the destruction." |
| 273 | +msgstr"" |
| 274 | + |
| 275 | +#:../../c-api/lifecycle.rst:208 |
| 276 | +msgid"" |
| 277 | +"Unlike clearing, finalization is not a phase of destruction. A finalized " |
| 278 | +"object must still behave properly by continuing to fulfill its design " |
| 279 | +"contracts. An object's finalizer is allowed to execute arbitrary Python " |
| 280 | +"code, and is even allowed to prevent the impending destruction by adding a " |
| 281 | +"reference. The finalizer is only related to destruction by call order---if " |
| 282 | +"it runs, it runs before destruction, which starts with :c:member:" |
| 283 | +"`~PyTypeObject.tp_clear` (if called) and concludes with :c:member:" |
| 284 | +"`~PyTypeObject.tp_dealloc`." |
| 285 | +msgstr"" |
| 286 | + |
| 287 | +#:../../c-api/lifecycle.rst:216 |
| 288 | +msgid"" |
| 289 | +"The finalization step is not necessary to safely reclaim the objects in a " |
| 290 | +"cyclic isolate, but its existence makes it easier to design types that " |
| 291 | +"behave in a sane manner when objects are cleared. Clearing an object might " |
| 292 | +"necessarily leave it in a broken, partially destroyed state---it might be " |
| 293 | +"unsafe to call any of the cleared object's methods or access any of its " |
| 294 | +"attributes. With finalization, only finalized objects can possibly interact " |
| 295 | +"with cleared objects; non-finalized objects are guaranteed to interact with " |
| 296 | +"only non-cleared (but potentially finalized) objects." |
| 297 | +msgstr"" |
| 298 | + |
| 299 | +#:../../c-api/lifecycle.rst:225 |
| 300 | +msgid"To summarize the possible interactions:" |
| 301 | +msgstr"" |
| 302 | + |
| 303 | +#:../../c-api/lifecycle.rst:227 |
| 304 | +msgid"" |
| 305 | +"A non-finalized object might have references to or from non-finalized and " |
| 306 | +"finalized objects, but not to or from cleared objects." |
| 307 | +msgstr"" |
| 308 | + |
| 309 | +#:../../c-api/lifecycle.rst:229 |
| 310 | +msgid"" |
| 311 | +"A finalized object might have references to or from non-finalized, " |
| 312 | +"finalized, and cleared objects." |
| 313 | +msgstr"" |
| 314 | + |
| 315 | +#:../../c-api/lifecycle.rst:231 |
| 316 | +msgid"" |
| 317 | +"A cleared object might have references to or from finalized and cleared " |
| 318 | +"objects, but not to or from non-finalized objects." |
| 319 | +msgstr"" |
| 320 | + |
| 321 | +#:../../c-api/lifecycle.rst:234 |
| 322 | +msgid"" |
| 323 | +"Without any reference cycles, an object can be simply destroyed once its " |
| 324 | +"last reference is deleted; the finalization and clearing steps are not " |
| 325 | +"necessary to safely reclaim unused objects. However, it can be useful to " |
| 326 | +"automatically call :c:member:`~PyTypeObject.tp_finalize` and :c:member:" |
| 327 | +"`~PyTypeObject.tp_clear` before destruction anyway because type design is " |
| 328 | +"simplified when all objects always experience the same series of events " |
| 329 | +"regardless of whether they participated in a cyclic isolate. Python " |
| 330 | +"currently only calls :c:member:`~PyTypeObject.tp_finalize` and :c:member:" |
| 331 | +"`~PyTypeObject.tp_clear` as needed to destroy a cyclic isolate; this may " |
| 332 | +"change in a future version." |
| 333 | +msgstr"" |
| 334 | + |
| 335 | +#:../../c-api/lifecycle.rst:246 |
| 336 | +msgid"Functions" |
| 337 | +msgstr"関数" |
| 338 | + |
| 339 | +#:../../c-api/lifecycle.rst:248 |
| 340 | +msgid"To allocate and free memory, see :ref:`allocating-objects`." |
| 341 | +msgstr"" |
| 342 | + |
| 343 | +#:../../c-api/lifecycle.rst:253 |
| 344 | +msgid"" |
| 345 | +"Finalizes the object as described in :c:member:`~PyTypeObject.tp_finalize`. " |
| 346 | +"Call this function (or :c:func:`PyObject_CallFinalizerFromDealloc`) instead " |
| 347 | +"of calling :c:member:`~PyTypeObject.tp_finalize` directly because this " |
| 348 | +"function may deduplicate multiple calls to :c:member:`!tp_finalize`. " |
| 349 | +"Currently, calls are only deduplicated if the type supports garbage " |
| 350 | +"collection (i.e., the :c:macro:`Py_TPFLAGS_HAVE_GC` flag is set); this may " |
| 351 | +"change in the future." |
| 352 | +msgstr"" |
| 353 | + |
| 354 | +#:../../c-api/lifecycle.rst:264 |
| 355 | +msgid"" |
| 356 | +"Same as :c:func:`PyObject_CallFinalizer` but meant to be called at the " |
| 357 | +"beginning of the object's destructor (:c:member:`~PyTypeObject.tp_dealloc`). " |
| 358 | +"There must not be any references to the object. If the object's finalizer " |
| 359 | +"resurrects the object, this function returns -1; no further destruction " |
| 360 | +"should happen. Otherwise, this function returns 0 and destruction can " |
| 361 | +"continue normally." |
| 362 | +msgstr"" |
| 363 | + |
| 364 | +#:../../c-api/lifecycle.rst:273 |
| 365 | +msgid":c:member:`~PyTypeObject.tp_dealloc` for example code." |
| 366 | +msgstr"" |
