-
-
Notifications
You must be signed in to change notification settings - Fork 53
Expand file tree
/
Copy pathlifecycle.po
More file actions
375 lines (329 loc) · 14.6 KB
/
lifecycle.po
File metadata and controls
375 lines (329 loc) · 14.6 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
# 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>, 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 <EMAIL@ADDRESS>\n"
"Language: ko\n"
"Language-Team: ko <LL@li.org>\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 "
"<cyclic isolate>`."
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 ""