iframe-proxy | Sunbelt Computer Software

627 lines (537 loc) · 22.6 KB
# 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.
# Translators:
# Rafael Fontenelle <rffontenelle@gmail.com>, 2026
# python-doc bot, 2026
"Project-Id-Version: Python 3.15\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2026-05-08 18:34+0000\n"
"PO-Revision-Date: 2026-02-25 14:46+0000\n"
"Last-Translator: python-doc bot, 2026\n"
"Language-Team: Portuguese (Brazil) (https://app.transifex.com/python-doc/"
"teams/5390/pt_BR/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: pt_BR\n"
"Plural-Forms: nplurals=3; plural=(n == 0 || n == 1) ? 0 : n != 0 && n % "
"1000000 == 0 ? 1 : 2;\n"
#: ../../c-api/subinterpreters.rst:6
msgid "Multiple interpreters in a Python process"
#: ../../c-api/subinterpreters.rst:8
"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."
#: ../../c-api/subinterpreters.rst:13
"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."
#: ../../c-api/subinterpreters.rst:20
"You can switch between sub-interpreters using the :c:func:"
"`PyThreadState_Swap` function. You can create and destroy them using the "
"following functions:"
#: ../../c-api/subinterpreters.rst:26
"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."
#: ../../c-api/subinterpreters.rst:32
msgid "Structure fields:"
msgstr "Campos de estrutura:"
#: ../../c-api/subinterpreters.rst:36
"If this is ``0`` then the sub-interpreter will use its own \"object\" "
"allocator state. Otherwise it will use (share) the main interpreter's."
#: ../../c-api/subinterpreters.rst:40
"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`."
#: ../../c-api/subinterpreters.rst:48
"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."
#: ../../c-api/subinterpreters.rst:52
"Note that the :mod:`subprocess` module still works when fork is disallowed."
#: ../../c-api/subinterpreters.rst:57
"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."
#: ../../c-api/subinterpreters.rst:62
"Note that the :mod:`subprocess` module still works when exec is disallowed."
#: ../../c-api/subinterpreters.rst:67
"If this is ``0`` then the sub-interpreter's :mod:`threading` module won't "
"create threads. Otherwise threads are allowed."
#: ../../c-api/subinterpreters.rst:73
"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)."
#: ../../c-api/subinterpreters.rst:80
"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`.)"
#: ../../c-api/subinterpreters.rst:87
"This must be ``1`` (non-zero) if :c:member:`~PyInterpreterConfig."
"use_main_obmalloc` is ``0``."
#: ../../c-api/subinterpreters.rst:92
"This determines the operation of the GIL for the sub-interpreter. It may be "
"one of the following:"
#: ../../c-api/subinterpreters.rst:99
msgid "Use the default selection (:c:macro:`PyInterpreterConfig_SHARED_GIL`)."
#: ../../c-api/subinterpreters.rst:103
msgid "Use (share) the main interpreter's GIL."
#: ../../c-api/subinterpreters.rst:107
msgid "Use the sub-interpreter's own GIL."
#: ../../c-api/subinterpreters.rst:109
"If this is :c:macro:`PyInterpreterConfig_OWN_GIL` then :c:member:"
"`PyInterpreterConfig.use_main_obmalloc` must be ``0``."
#: ../../c-api/subinterpreters.rst:123
"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)."
#: ../../c-api/subinterpreters.rst:133
"The given *config* controls the options with which the interpreter is "
"initialized."
#: ../../c-api/subinterpreters.rst:136
"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."
#: ../../c-api/subinterpreters.rst:145
"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."
#: ../../c-api/subinterpreters.rst:156
"Sub-interpreters are most effective when isolated from each other, with "
"certain functionality restricted::"
#: ../../c-api/subinterpreters.rst:159
"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"
"PyThreadState *tstate = NULL;\n"
"PyStatus status = Py_NewInterpreterFromConfig(&tstate, &config);\n"
"if (PyStatus_Exception(status)) {\n"
"    Py_ExitStatusException(status);\n"
#: ../../c-api/subinterpreters.rst:174
"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`."
#: ../../c-api/subinterpreters.rst:183
msgid "Extension modules are shared between (sub-)interpreters as follows:"
#: ../../c-api/subinterpreters.rst:185
"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."
#: ../../c-api/subinterpreters.rst:191
"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)."
#: ../../c-api/subinterpreters.rst:203
"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."
#: ../../c-api/subinterpreters.rst:223
"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."
#: ../../c-api/subinterpreters.rst:235
"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."
#: ../../c-api/subinterpreters.rst:240
":c:func:`Py_FinalizeEx` will destroy all sub-interpreters that haven't been "
"explicitly destroyed at that point."
#: ../../c-api/subinterpreters.rst:247
msgid "A per-interpreter GIL"
#: ../../c-api/subinterpreters.rst:251
"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`.)"
#: ../../c-api/subinterpreters.rst:261
"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."
#: ../../c-api/subinterpreters.rst:272
"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."
"Se você preservar o isolamento, terá acesso à computação multi-core "
"adequada, sem as complicações que acompanham o uso de threads livres. A "
"falha em preservar o isolamento traz a exposição a todas as consequências de "
"threads livres, incluindo corridas e travamentos difíceis de depurar."
#: ../../c-api/subinterpreters.rst:277
"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."
#: ../../c-api/subinterpreters.rst:286
msgid "Bugs and caveats"
#: ../../c-api/subinterpreters.rst:288
"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."
#: ../../c-api/subinterpreters.rst:298
"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."
#: ../../c-api/subinterpreters.rst:304
"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."
#: ../../c-api/subinterpreters.rst:315
msgid "High-level APIs"
msgstr "APIs de alto nível"
#: ../../c-api/subinterpreters.rst:319
"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."
#: ../../c-api/subinterpreters.rst:324
"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."
#: ../../c-api/subinterpreters.rst:331
":pep:`684` introduced the possibility of a :ref:`per-interpreter GIL <per-"
"interpreter-gil>`. See :c:func:`Py_NewInterpreterFromConfig`."
#: ../../c-api/subinterpreters.rst:338
msgid "Get the current interpreter."
#: ../../c-api/subinterpreters.rst:340
"Issue a fatal error if there is no :term:`attached thread state`. It cannot "
"return NULL."
#: ../../c-api/subinterpreters.rst:348
"Return the interpreter's unique ID.  If there was any error in doing so then "
"``-1`` is returned and an error is set."
#: ../../c-api/subinterpreters.rst:351
msgid "The caller must have an :term:`attached thread state`."
msgstr "O chamador deve ter um :term:`estado de thread anexado`."
#: ../../c-api/subinterpreters.rst:358
"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."
#: ../../c-api/subinterpreters.rst:362
"This is not a replacement for :c:func:`PyModule_GetState()`, which "
"extensions should use to store interpreter-specific state information."
#: ../../c-api/subinterpreters.rst:365
"The returned dictionary is borrowed from the interpreter and is valid until "
"interpreter shutdown."
#: ../../c-api/subinterpreters.rst:373
msgid "Type of a frame evaluation function."
#: ../../c-api/subinterpreters.rst:375
"The *throwflag* parameter is used by the ``throw()`` method of generators: "
"if non-zero, handle the current exception."
#: ../../c-api/subinterpreters.rst:378
msgid "The function now takes a *tstate* parameter."
#: ../../c-api/subinterpreters.rst:381
"The *frame* parameter changed from ``PyFrameObject*`` to "
"``_PyInterpreterFrame*``."
#: ../../c-api/subinterpreters.rst:387
msgid "Get the frame evaluation function."
#: ../../c-api/subinterpreters.rst:389 ../../c-api/subinterpreters.rst:398
msgid "See the :pep:`523` \"Adding a frame evaluation API to CPython\"."
#: ../../c-api/subinterpreters.rst:396
msgid "Set the frame evaluation function."
#: ../../c-api/subinterpreters.rst:404
"Enables or disables specialization why a custom frame evaluator is in place."
#: ../../c-api/subinterpreters.rst:406
"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."
#: ../../c-api/subinterpreters.rst:417
"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."
#: ../../c-api/subinterpreters.rst:425
msgid "Low-level APIs"
msgstr "APIs de baixo nível"
#: ../../c-api/subinterpreters.rst:427
"All of the following functions must be called after :c:func:`Py_Initialize`."
#: ../../c-api/subinterpreters.rst:429
":c:func:`Py_Initialize()` now initializes the :term:`GIL` and sets an :term:"
"`attached thread state`."
#: ../../c-api/subinterpreters.rst:436
"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."
#: ../../c-api/subinterpreters.rst:440
"Raises an :ref:`auditing event <auditing>` ``cpython."
"PyInterpreterState_New`` with no arguments."
"Levanta um :ref:`evento de auditoria <auditing>` ``cpython."
"PyInterpreterState_New`` sem argumentos."
#: ../../c-api/subinterpreters.rst:445
"Reset all information in an interpreter state object.  There must be an :"
"term:`attached thread state` for the interpreter."
#: ../../c-api/subinterpreters.rst:448
"Raises an :ref:`auditing event <auditing>` ``cpython."
"PyInterpreterState_Clear`` with no arguments."
"Levanta um :ref:`evento de auditoria <auditing>` ``cpython."
"PyInterpreterState_Clear`` sem argumentos."
#: ../../c-api/subinterpreters.rst:453
"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`."
#: ../../c-api/subinterpreters.rst:461
msgid "Advanced debugger support"
#: ../../c-api/subinterpreters.rst:463
"These functions are only intended to be used by advanced debugging tools."
#: ../../c-api/subinterpreters.rst:468
"Return the interpreter state object at the head of the list of all such "
#: ../../c-api/subinterpreters.rst:473
msgid "Return the main interpreter state object."
#: ../../c-api/subinterpreters.rst:478
"Return the next interpreter state object after *interp* from the list of all "
"such objects."
#: ../../c-api/subinterpreters.rst:484
"Return the pointer to the first :c:type:`PyThreadState` object in the list "
"of threads associated with the interpreter *interp*."
#: ../../c-api/subinterpreters.rst:490
"Return the next thread state object after *tstate* from the list of all such "
"objects belonging to the same :c:type:`PyInterpreterState` object."
#: ../../c-api/subinterpreters.rst:115 ../../c-api/subinterpreters.rst:215
msgid "module"
msgstr "module"
#: ../../c-api/subinterpreters.rst:115 ../../c-api/subinterpreters.rst:215
msgid "builtins"
msgstr "builtins"
#: ../../c-api/subinterpreters.rst:115 ../../c-api/subinterpreters.rst:215
msgid "__main__"
msgstr "__main__"
#: ../../c-api/subinterpreters.rst:115 ../../c-api/subinterpreters.rst:215
msgid "sys"
msgstr "sys"
#: ../../c-api/subinterpreters.rst:115 ../../c-api/subinterpreters.rst:215
msgid "stdout (in module sys)"
msgstr "stdout (no módulo sys)"
#: ../../c-api/subinterpreters.rst:115 ../../c-api/subinterpreters.rst:215
msgid "stderr (in module sys)"
msgstr "stderr (no módulo sys)"
#: ../../c-api/subinterpreters.rst:115 ../../c-api/subinterpreters.rst:215
msgid "stdin (in module sys)"
msgstr "stdin (no módulo sys)"
#: ../../c-api/subinterpreters.rst:179 ../../c-api/subinterpreters.rst:233
msgid "Py_FinalizeEx (C function)"
msgstr "Py_FinalizeEx (função C)"
#: ../../c-api/subinterpreters.rst:179
msgid "Py_Initialize (C function)"
msgstr "Py_Initialize (função C)"
#: ../../c-api/subinterpreters.rst:210
msgid "close (in module os)"
Sunbelt Computer Software

PL/B Language Development and Support

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

Uh oh!

FilesExpand file tree

subinterpreters.po

Latest commit

History

subinterpreters.po

File metadata and controls
