python-docs-pl/c-api/subinterpreters.po at 3.15 · python/python-docs-pl · GitHub

Repository navigation

History

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

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

# SOME DESCRIPTIVE TITLE.

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

# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.

# Translators:

# Rafael Fontenelle <rffontenelle@gmail.com>, 2026

# python-doc bot, 2026

#, fuzzy

msgid ""

msgstr ""

"Project-Id-Version: Python 3.15\n"

"Report-Msgid-Bugs-To: \n"

"POT-Creation-Date: 2026-09-29 18:58+0000\n"

"PO-Revision-Date: 2026-02-25 14:46+0000\n"

"Last-Translator: python-doc bot, 2026\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 "Multiple interpreters in a Python process"

msgstr ""

msgid ""

"While in most uses, you will only embed a single Python interpreter, there "

"are cases where you need to create several independent interpreters in the "

"same process and perhaps even in the same thread. Sub-interpreters allow you "

"to do that."

msgstr ""

msgid ""

"The \"main\" interpreter is the first one created when the runtime "

"initializes. It is usually the only Python interpreter in a process. Unlike "

"sub-interpreters, the main interpreter has unique process-global "

"responsibilities like signal handling. It is also responsible for execution "

"during runtime initialization and is usually the active interpreter during "

"runtime finalization. The :c:func:`PyInterpreterState_Main` function "

"returns a pointer to its state."

msgstr ""

msgid ""

"You can switch between sub-interpreters using the :c:func:"

"`PyThreadState_Swap` function. You can create and destroy them using the "

"following functions:"

msgstr ""

msgid ""

"Structure containing most parameters to configure a sub-interpreter. Its "

"values are used only in :c:func:`Py_NewInterpreterFromConfig` and never "

"modified by the runtime."

msgstr ""

msgid "Structure fields:"

msgstr ""

msgid ""

"If this is ``0`` then the sub-interpreter will use its own \"object\" "

"allocator state. Otherwise it will use (share) the main interpreter's."

msgstr ""

msgid ""

"If this is ``0`` then :c:member:`~PyInterpreterConfig."

"check_multi_interp_extensions` must be ``1`` (non-zero). If this is ``1`` "

"then :c:member:`~PyInterpreterConfig.gil` must not be :c:macro:"

"`PyInterpreterConfig_OWN_GIL`."

msgstr ""

msgid ""

"If this is ``0`` then the runtime will not support forking the process in "

"any thread where the sub-interpreter is currently active. Otherwise fork is "

"unrestricted."

msgstr ""

msgid ""

"Note that the :mod:`subprocess` module still works when fork is disallowed."

msgstr ""

msgid ""

"If this is ``0`` then the runtime will not support replacing the current "

"process via exec (e.g. :func:`os.execv`) in any thread where the sub-"

"interpreter is currently active. Otherwise exec is unrestricted."

msgstr ""

msgid ""

"Note that the :mod:`subprocess` module still works when exec is disallowed."

msgstr ""

msgid ""

"If this is ``0`` then the sub-interpreter's :mod:`threading` module won't "

"create threads. Otherwise threads are allowed."

msgstr ""

msgid ""

"If this is ``0`` then the sub-interpreter's :mod:`threading` module won't "

"create daemon threads. Otherwise daemon threads are allowed (as long as :c:"

"member:`~PyInterpreterConfig.allow_threads` is non-zero)."

msgstr ""

msgid ""

"If this is ``0`` then all extension modules may be imported, including "

"legacy (single-phase init) modules, in any thread where the sub-interpreter "

"is currently active. Otherwise only multi-phase init extension modules (see :"

"pep:`489`) may be imported. (Also see :c:macro:"

"`Py_mod_multiple_interpreters`.)"

msgstr ""

msgid ""

"This must be ``1`` (non-zero) if :c:member:`~PyInterpreterConfig."

"use_main_obmalloc` is ``0``."

msgstr ""

msgid ""

"This determines the operation of the GIL for the sub-interpreter. It may be "

"one of the following:"

msgstr ""

msgid "Use the default selection (:c:macro:`PyInterpreterConfig_SHARED_GIL`)."

msgstr ""

msgid "Use (share) the main interpreter's GIL."

msgstr ""

msgid "Use the sub-interpreter's own GIL."

msgstr ""

msgid ""

"If this is :c:macro:`PyInterpreterConfig_OWN_GIL` then :c:member:"

"`PyInterpreterConfig.use_main_obmalloc` must be ``0``."

msgstr ""

msgid ""

"Create a new sub-interpreter. This is an (almost) totally separate "

"environment for the execution of Python code. In particular, the new "

"interpreter has separate, independent versions of all imported modules, "

"including the fundamental modules :mod:`builtins`, :mod:`__main__` and :mod:"

"`sys`. The table of loaded modules (``sys.modules``) and the module search "

"path (``sys.path``) are also separate. The new environment has no ``sys."

"argv`` variable. It has new standard I/O stream file objects ``sys.stdin``, "

"``sys.stdout`` and ``sys.stderr`` (however these refer to the same "

"underlying file descriptors)."

msgstr ""

msgid ""

"The given *config* controls the options with which the interpreter is "

"initialized."

msgstr ""

msgid ""

"Upon success, *tstate_p* will be set to the first :term:`thread state` "

"created in the new sub-interpreter. This thread state is :term:`attached "

"<attached thread state>`. Note that no actual thread is created; see the "

"discussion of thread states below. If creation of the new interpreter is "

"unsuccessful, *tstate_p* is set to ``NULL``; no exception is set since the "

"exception state is stored in the :term:`attached thread state`, which might "

"not exist."

msgstr ""

msgid ""

"Like all other Python/C API functions, an :term:`attached thread state` must "

"be present before calling this function, but it might be detached upon "

"returning. On success, the returned thread state will be :term:`attached "

"<attached thread state>`. If the sub-interpreter is created with its own :"

"term:`GIL` then the :term:`attached thread state` of the calling interpreter "

"will be detached. When the function returns, the new interpreter's :term:"

"`thread state` will be :term:`attached <attached thread state>` to the "

"current thread and the previous interpreter's :term:`attached thread state` "

"will remain detached."

msgstr ""

msgid ""

"Sub-interpreters are most effective when isolated from each other, with "

"certain functionality restricted::"

msgstr ""

msgid ""

"PyInterpreterConfig config = {\n"

" .use_main_obmalloc = 0,\n"

" .allow_fork = 0,\n"

" .allow_exec = 0,\n"

" .allow_threads = 1,\n"

" .allow_daemon_threads = 0,\n"

" .check_multi_interp_extensions = 1,\n"

" .gil = PyInterpreterConfig_OWN_GIL,\n"

"};\n"

"PyThreadState *tstate = NULL;\n"

"PyStatus status = Py_NewInterpreterFromConfig(&tstate, &config);\n"

"if (PyStatus_Exception(status)) {\n"

" Py_ExitStatusException(status);\n"

"}"

msgstr ""

msgid ""

"Note that the config is used only briefly and does not get modified. During "

"initialization the config's values are converted into various :c:type:"

"`PyInterpreterState` values. A read-only copy of the config may be stored "

"internally on the :c:type:`PyInterpreterState`."

msgstr ""

msgid "Extension modules are shared between (sub-)interpreters as follows:"

msgstr ""

msgid ""

"For modules using multi-phase initialization, e.g. :c:func:"

"`PyModule_FromDefAndSpec`, a separate module object is created and "

"initialized for each interpreter. Only C-level static and global variables "

"are shared between these module objects."

msgstr ""

msgid ""

"For modules using legacy :ref:`single-phase initialization <single-phase-"

"initialization>`, e.g. :c:func:`PyModule_Create`, the first time a "

"particular extension is imported, it is initialized normally, and a "

"(shallow) copy of its module's dictionary is squirreled away. When the same "

"extension is imported by another (sub-)interpreter, a new module is "

"initialized and filled with the contents of this copy; the extension's "

"``init`` function is not called. Objects in the module's dictionary thus end "

"up shared across (sub-)interpreters, which might cause unwanted behavior "

"(see `Bugs and caveats`_ below)."

msgstr ""

msgid ""

"Note that this is different from what happens when an extension is imported "

"after the interpreter has been completely re-initialized by calling :c:func:"

"`Py_FinalizeEx` and :c:func:`Py_Initialize`; in that case, the extension's "

"``initmodule`` function *is* called again. As with multi-phase "

"initialization, this means that only C-level static and global variables are "

"shared between these modules."

msgstr ""

msgid ""

"Create a new sub-interpreter. This is essentially just a wrapper around :c:"

"func:`Py_NewInterpreterFromConfig` with a config that preserves the existing "

"behavior. The result is an unisolated sub-interpreter that shares the main "

"interpreter's GIL, allows fork/exec, allows daemon threads, and allows "

"single-phase init modules."

msgstr ""

msgid ""

"Destroy the (sub-)interpreter represented by the given :term:`thread state`. "

"The given thread state must be :term:`attached <attached thread state>`. "

"When the call returns, there will be no :term:`attached thread state`. All "

"thread states associated with this interpreter are destroyed."

msgstr ""

msgid ""

":c:func:`Py_FinalizeEx` will destroy all sub-interpreters that haven't been "

"explicitly destroyed at that point."

msgstr ""

msgid "A per-interpreter GIL"

msgstr ""

msgid ""

"Using :c:func:`Py_NewInterpreterFromConfig` you can create a sub-interpreter "

"that is completely isolated from other interpreters, including having its "

"own GIL. The most important benefit of this isolation is that such an "

"interpreter can execute Python code without being blocked by other "

"interpreters or blocking any others. Thus a single Python process can truly "

"take advantage of multiple CPU cores when running Python code. The "

"isolation also encourages a different approach to concurrency than that of "

"just using threads. (See :pep:`554` and :pep:`684`.)"

msgstr ""

msgid ""

"Using an isolated interpreter requires vigilance in preserving that "

"isolation. That especially means not sharing any objects or mutable state "

"without guarantees about thread-safety. Even objects that are otherwise "

"immutable (e.g. ``None``, ``(1, 5)``) can't normally be shared because of "

"the refcount. One simple but less-efficient approach around this is to use "

"a global lock around all use of some state (or object). Alternately, "

"effectively immutable objects (like integers or strings) can be made safe in "

"spite of their refcounts by making them :term:`immortal`. In fact, this has "

"been done for the builtin singletons, small integers, and a number of other "

"builtin objects."

msgstr ""

msgid ""

"If you preserve isolation then you will have access to proper multi-core "

"computing without the complications that come with free-threading. Failure "

"to preserve isolation will expose you to the full consequences of free-"

"threading, including races and hard-to-debug crashes."

msgstr ""

msgid ""

"Aside from that, one of the main challenges of using multiple isolated "

"interpreters is how to communicate between them safely (not break isolation) "

"and efficiently. The runtime and stdlib do not provide any standard "

"approach to this yet. A future stdlib module would help mitigate the effort "

"of preserving isolation and expose effective tools for communicating (and "

"sharing) data between interpreters."

msgstr ""

msgid "Bugs and caveats"

msgstr ""

msgid ""

"Because sub-interpreters (and the main interpreter) are part of the same "

"process, the insulation between them isn't perfect --- for example, using "

"low-level file operations like :func:`os.close` they can (accidentally or "

"maliciously) affect each other's open files. Because of the way extensions "

"are shared between (sub-)interpreters, some extensions may not work "

"properly; this is especially likely when using single-phase initialization "

"or (static) global variables. It is possible to insert objects created in "

"one sub-interpreter into a namespace of another (sub-)interpreter; this "

"should be avoided if possible."

msgstr ""

msgid ""

"Special care should be taken to avoid sharing user-defined functions, "

"methods, instances or classes between sub-interpreters, since import "

"operations executed by such objects may affect the wrong (sub-)interpreter's "

"dictionary of loaded modules. It is equally important to avoid sharing "

"objects from which the above are reachable."

msgstr ""

msgid ""

"Also note that combining this functionality with ``PyGILState_*`` APIs is "

"delicate, because these APIs assume a bijection between Python thread states "

"and OS-level threads, an assumption broken by the presence of sub-"

"interpreters. It is highly recommended that you don't switch sub-"

"interpreters between a pair of matching :c:func:`PyGILState_Ensure` and :c:"

"func:`PyGILState_Release` calls. Furthermore, extensions (such as :mod:"

"`ctypes`) using these APIs to allow calling of Python code from non-Python "

"created threads will probably be broken when using sub-interpreters."

msgstr ""

msgid "High-level APIs"

msgstr "Wysokopoziomowe interfejsy API"

msgid ""

"This data structure represents the state shared by a number of cooperating "

"threads. Threads belonging to the same interpreter share their module "

"administration and a few other internal items. There are no public members "

"in this structure."

msgstr ""

msgid ""

"Threads belonging to different interpreters initially share nothing, except "

"process state like available memory, open file descriptors and such. The "

"global interpreter lock is also shared by all threads, regardless of to "

"which interpreter they belong."

msgstr ""

msgid ""

":pep:`684` introduced the possibility of a :ref:`per-interpreter GIL <per-"

"interpreter-gil>`. See :c:func:`Py_NewInterpreterFromConfig`."

msgstr ""

msgid "Get the current interpreter."

msgstr ""

msgid ""

"Issue a fatal error if there is no :term:`attached thread state`. It cannot "

"return NULL."

msgstr ""

msgid ""

"Return the interpreter's unique ID. If there was any error in doing so then "

"``-1`` is returned and an error is set."

msgstr ""

msgid "The caller must have an :term:`attached thread state`."

msgstr ""

msgid ""

"Return a dictionary in which interpreter-specific data may be stored. If "

"this function returns ``NULL`` then no exception has been raised and the "

"caller should assume no interpreter-specific dict is available."

msgstr ""

msgid ""

"This is not a replacement for :c:func:`PyModule_GetState()`, which "

"extensions should use to store interpreter-specific state information."

msgstr ""

msgid ""

"The returned dictionary is borrowed from the interpreter and is valid until "

"interpreter shutdown."

msgstr ""

msgid "Type of a frame evaluation function."

msgstr ""

msgid ""

"The *throwflag* parameter is used by the ``throw()`` method of generators: "

"if non-zero, handle the current exception."

msgstr ""

msgid "The function now takes a *tstate* parameter."

msgstr ""

msgid ""

"The *frame* parameter changed from ``PyFrameObject*`` to "

"``_PyInterpreterFrame*``."

msgstr ""

msgid "Get the frame evaluation function."

msgstr ""

msgid "See the :pep:`523` \"Adding a frame evaluation API to CPython\"."

msgstr ""

msgid "Set the frame evaluation function."

msgstr ""

msgid ""

"Enables or disables specialization why a custom frame evaluator is in place."

msgstr ""

msgid ""

"If *allow_specialization* is non-zero, the adaptive specializer will "

"continue to specialize bytecodes even though a custom eval frame function is "

"set. When *allow_specialization* is zero, setting a custom eval frame "

"disables specialization. The standard interpreter loop will continue to "

"deopt while a frame evaluation API is in place - the frame evaluation "

"function needs to handle the specialized opcodes to take advantage of this."

msgstr ""

msgid ""

"Return non-zero if adaptive specialization is enabled for the interpreter. "

"Specialization is enabled when no custom eval frame function is set, or when "

"one is set with *allow_specialization* enabled."

msgstr ""

msgid "Low-level APIs"

msgstr "niskopoziomowe interfejsy API"

msgid ""

"All of the following functions must be called after :c:func:`Py_Initialize`."

msgstr ""

msgid ""

":c:func:`Py_Initialize()` now initializes the :term:`GIL` and sets an :term:"

"`attached thread state`."

msgstr ""

msgid ""

"Create a new interpreter state object. An :term:`attached thread state` is "

"not needed, but may optionally exist if it is necessary to serialize calls "

"to this function."

msgstr ""

msgid ""

"Raises an :ref:`auditing event <auditing>` ``cpython."

"PyInterpreterState_New`` with no arguments."

msgstr ""

msgid ""

"Reset all information in an interpreter state object. There must be an :"

"term:`attached thread state` for the interpreter."

msgstr ""

msgid ""

"Raises an :ref:`auditing event <auditing>` ``cpython."

"PyInterpreterState_Clear`` with no arguments."

msgstr ""

msgid ""

"Destroy an interpreter state object. There **should not** be an :term:"

"`attached thread state` for the target interpreter. The interpreter state "

"must have been reset with a previous call to :c:func:"

"`PyInterpreterState_Clear`."

msgstr ""

msgid "Advanced debugger support"

msgstr ""

msgid ""

"These functions are only intended to be used by advanced debugging tools."

msgstr ""

msgid ""

"Return the interpreter state object at the head of the list of all such "

"objects."

msgstr ""

msgid "Return the main interpreter state object."

msgstr ""

msgid ""

"Return the next interpreter state object after *interp* from the list of all "

"such objects."

msgstr ""

msgid ""

"Return the pointer to the first :c:type:`PyThreadState` object in the list "

"of threads associated with the interpreter *interp*."

msgstr ""

msgid ""

"Return the next thread state object after *tstate* from the list of all such "

"objects belonging to the same :c:type:`PyInterpreterState` object."

msgstr ""

msgid "module"

msgstr "moduł"

msgid "builtins"

msgstr "builtins"

msgid "__main__"

msgstr "__main__"

msgid "sys"

msgstr "sys"

msgid "stdout (in module sys)"

msgstr ""

msgid "stderr (in module sys)"

msgstr ""

msgid "stdin (in module sys)"

msgstr ""

msgid "Py_FinalizeEx (C function)"

msgstr ""

msgid "Py_Initialize (C function)"

msgstr ""

msgid "close (in module os)"

msgstr ""

python-docs-pl/c-api/subinterpreters.po at 3.15 · python/python-docs-pl · GitHub

Repository navigation

Expand file tree

Breadcrumbs

subinterpreters.po

Latest commit

History

Breadcrumbs

subinterpreters.po

File metadata and controls