GeezerVison is showing github.com — python-docs-ru/c-api/lifecycle.po at 3.15 · python/python-docs-ru

Expand file tree

lifecycle.po

Copy path

More file actions

Latest commit

History

327 lines (282 loc) · 13.3 KB

lifecycle.po

Copy path

File metadata and controls

327 lines (282 loc) · 13.3 KB

Raw

Copy raw file

Download raw file

Open symbols panel

Edit and raw actions

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

# SOME DESCRIPTIVE TITLE.

# This file is distributed under the same license as the Python package.

# FIRST AUTHOR <EMAIL@ADDRESS>, 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-11-01 18:39+0000\n"

"PO-Revision-Date: 2025-09-16 00:00+0000\n"

"Last-Translator: python-doc bot, 2025\n"

"Language-Team: Russian (https://app.transifex.com/python-doc/teams/5390/"

"ru/)\n"

"MIME-Version: 1.0\n"

"Content-Type: text/plain; charset=UTF-8\n"

"Content-Transfer-Encoding: 8bit\n"

"Language: ru\n"

"Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && "

"n%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9) || "

"(n%100>=11 && 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 <cyclic isolate>`."

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

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