Repository navigation
Expand file tree
/
Copy pathsubinterpreters.po
More file actions
554 lines (475 loc) · 19.6 KB
/
Copy pathsubinterpreters.po
File metadata and controls
554 lines (475 loc) · 19.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
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
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
# 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.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Python 3.15\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2026-10-17 14:27+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: c-api/subinterpreters.rst:6
msgid "Multiple interpreters in a Python process"
msgstr ""
#: c-api/subinterpreters.rst:8
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 ""
#: c-api/subinterpreters.rst:13
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 ""
#: c-api/subinterpreters.rst:20
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 ""
#: c-api/subinterpreters.rst:26
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 ""
#: c-api/subinterpreters.rst:32
msgid "Structure fields:"
msgstr ""
#: c-api/subinterpreters.rst:36
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 ""
#: c-api/subinterpreters.rst:40
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 ""
#: c-api/subinterpreters.rst:48
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 ""
#: c-api/subinterpreters.rst:52
msgid ""
"Note that the :mod:`subprocess` module still works when fork is disallowed."
msgstr ""
#: c-api/subinterpreters.rst:57
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 ""
#: c-api/subinterpreters.rst:62
msgid ""
"Note that the :mod:`subprocess` module still works when exec is disallowed."
msgstr ""
#: c-api/subinterpreters.rst:67
msgid ""
"If this is ``0`` then the sub-interpreter's :mod:`threading` module won't "
"create threads. Otherwise threads are allowed."
msgstr ""
#: c-api/subinterpreters.rst:73
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 ""
#: c-api/subinterpreters.rst:80
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 ""
#: c-api/subinterpreters.rst:87
msgid ""
"This must be ``1`` (non-zero) "
"if :c:member:`~PyInterpreterConfig.use_main_obmalloc` is ``0``."
msgstr ""
#: c-api/subinterpreters.rst:92
msgid ""
"This determines the operation of the GIL for the sub-interpreter. It may be "
"one of the following:"
msgstr ""
#: c-api/subinterpreters.rst:99
msgid "Use the default selection (:c:macro:`PyInterpreterConfig_SHARED_GIL`)."
msgstr ""
#: c-api/subinterpreters.rst:103
msgid "Use (share) the main interpreter's GIL."
msgstr ""
#: c-api/subinterpreters.rst:107
msgid "Use the sub-interpreter's own GIL."
msgstr ""
#: c-api/subinterpreters.rst:109
msgid ""
"If this is :c:macro:`PyInterpreterConfig_OWN_GIL` "
"then :c:member:`PyInterpreterConfig.use_main_obmalloc` must be ``0``."
msgstr ""
#: c-api/subinterpreters.rst:123
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 ""
#: c-api/subinterpreters.rst:133
msgid ""
"The given *config* controls the options with which the interpreter is "
"initialized."
msgstr ""
#: c-api/subinterpreters.rst:136
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 ""
#: c-api/subinterpreters.rst:145
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 ""
#: c-api/subinterpreters.rst:156
msgid ""
"Sub-interpreters are most effective when isolated from each other, with "
"certain functionality restricted::"
msgstr ""
#: c-api/subinterpreters.rst:174
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 ""
#: c-api/subinterpreters.rst:183
msgid "Extension modules are shared between (sub-)interpreters as follows:"
msgstr ""
#: c-api/subinterpreters.rst:185
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 ""
#: c-api/subinterpreters.rst:191
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 ""
#: c-api/subinterpreters.rst:203
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 ""
#: c-api/subinterpreters.rst:223
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 ""
#: c-api/subinterpreters.rst:235
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 ""
#: c-api/subinterpreters.rst:240
msgid ""
":c:func:`Py_FinalizeEx` will destroy all sub-interpreters that haven't been "
"explicitly destroyed at that point."
msgstr ""
#: c-api/subinterpreters.rst:247
msgid "A per-interpreter GIL"
msgstr ""
#: c-api/subinterpreters.rst:251
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 ""
#: c-api/subinterpreters.rst:261
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 ""
#: c-api/subinterpreters.rst:272
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 ""
#: c-api/subinterpreters.rst:277
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 ""
#: c-api/subinterpreters.rst:286
msgid "Bugs and caveats"
msgstr ""
#: c-api/subinterpreters.rst:288
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 ""
#: c-api/subinterpreters.rst:298
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 ""
#: c-api/subinterpreters.rst:304
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 ""
#: c-api/subinterpreters.rst:315
msgid "High-level APIs"
msgstr ""
#: c-api/subinterpreters.rst:319
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 ""
#: c-api/subinterpreters.rst:324
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 ""
#: c-api/subinterpreters.rst:331
msgid ""
":pep:`684` introduced the possibility of a :ref:`per-interpreter GIL <per-"
"interpreter-gil>`. See :c:func:`Py_NewInterpreterFromConfig`."
msgstr ""
#: c-api/subinterpreters.rst:338
msgid "Get the current interpreter."
msgstr ""
#: c-api/subinterpreters.rst:340
msgid ""
"Issue a fatal error if there is no :term:`attached thread state`. It cannot "
"return NULL."
msgstr ""
#: c-api/subinterpreters.rst:348
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 ""
#: c-api/subinterpreters.rst:351
msgid "The caller must have an :term:`attached thread state`."
msgstr ""
#: c-api/subinterpreters.rst:358
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 ""
#: c-api/subinterpreters.rst:362
msgid ""
"This is not a replacement for :c:func:`PyModule_GetState()`, which "
"extensions should use to store interpreter-specific state information."
msgstr ""
#: c-api/subinterpreters.rst:365
msgid ""
"The returned dictionary is borrowed from the interpreter and is valid until "
"interpreter shutdown."
msgstr ""
#: c-api/subinterpreters.rst:373
msgid "Type of a frame evaluation function."
msgstr ""
#: c-api/subinterpreters.rst:375
msgid ""
"The *throwflag* parameter is used by the ``throw()`` method of generators: "
"if non-zero, handle the current exception."
msgstr ""
#: c-api/subinterpreters.rst:378
msgid "The function now takes a *tstate* parameter."
msgstr ""
#: c-api/subinterpreters.rst:381
msgid ""
"The *frame* parameter changed from ``PyFrameObject*`` to "
"``_PyInterpreterFrame*``."
msgstr ""
#: c-api/subinterpreters.rst:387
msgid "Get the frame evaluation function."
msgstr ""
#: c-api/subinterpreters.rst:398
msgid "See the :pep:`523` \"Adding a frame evaluation API to CPython\"."
msgstr ""
#: c-api/subinterpreters.rst:396
msgid "Set the frame evaluation function."
msgstr ""
#: c-api/subinterpreters.rst:404
msgid ""
"Enables or disables specialization why a custom frame evaluator is in place."
msgstr ""
#: c-api/subinterpreters.rst:406
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 ""
#: c-api/subinterpreters.rst:417
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 ""
#: c-api/subinterpreters.rst:425
msgid "Low-level APIs"
msgstr ""
#: c-api/subinterpreters.rst:427
msgid ""
"All of the following functions must be called after :c:func:`Py_Initialize`."
msgstr ""
#: c-api/subinterpreters.rst:429
msgid ""
":c:func:`Py_Initialize()` now initializes the :term:`GIL` and sets "
"an :term:`attached thread state`."
msgstr ""
#: c-api/subinterpreters.rst:436
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 ""
#: c-api/subinterpreters.rst:440
msgid ""
"Raises an :ref:`auditing event <auditing>` "
"``cpython.PyInterpreterState_New`` with no arguments."
msgstr ""
#: c-api/subinterpreters.rst:445
msgid ""
"Reset all information in an interpreter state object. There must be "
"an :term:`attached thread state` for the interpreter."
msgstr ""
#: c-api/subinterpreters.rst:448
msgid ""
"Raises an :ref:`auditing event <auditing>` "
"``cpython.PyInterpreterState_Clear`` with no arguments."
msgstr ""
#: c-api/subinterpreters.rst:453
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 ""
#: c-api/subinterpreters.rst:461
msgid "Advanced debugger support"
msgstr ""
#: c-api/subinterpreters.rst:463
msgid ""
"These functions are only intended to be used by advanced debugging tools."
msgstr ""
#: c-api/subinterpreters.rst:468
msgid ""
"Return the interpreter state object at the head of the list of all such "
"objects."
msgstr ""
#: c-api/subinterpreters.rst:473
msgid "Return the main interpreter state object."
msgstr ""
#: c-api/subinterpreters.rst:478
msgid ""
"Return the next interpreter state object after *interp* from the list of all "
"such objects."
msgstr ""
#: c-api/subinterpreters.rst:484
msgid ""
"Return the pointer to the first :c:type:`PyThreadState` object in the list "
"of threads associated with the interpreter *interp*."
msgstr ""
#: c-api/subinterpreters.rst:490
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 ""