@@ -12,7 +12,7 @@ msgid ""
1212msgstr ""
1313"Project-Id-Version : Python 3.14\n "
1414"Report-Msgid-Bugs-To : \n "
15- "POT-Creation-Date : 2025-05-23 14:20+0000\n "
15+ "POT-Creation-Date : 2025-06-06 14:20+0000\n "
1616"PO-Revision-Date : 2021-06-28 00:49+0000\n "
1717"Last-Translator : haaritsubaki, 2023\n "
1818"Language-Team : Polish (https://app.transifex.com/python-doc/teams/5390/pl/)\n "
@@ -266,26 +266,46 @@ msgid ""
266266"initialization\" . Extension modules created this way behave more like Python "
267267"modules: the initialization is split between the *creation phase*, when the "
268268"module object is created, and the *execution phase*, when it is populated. "
269- "The distinction is similar to the :py:meth:`! __new__` and :py:meth:`! "
270- "__init__` methods of classes."
269+ "The distinction is similar to the :py:meth:`~object. __new__` and :py:meth:"
270+ "`~object. __init__` methods of classes."
271271msgstr ""
272272
273273msgid ""
274274"Unlike modules created using single-phase initialization, these modules are "
275- "not singletons: if the *sys.modules* entry is removed and the module is re-"
276- "imported, a new module object is created, and the old module is subject to "
277- "normal garbage collection -- as with Python modules. By default, multiple "
278- "modules created from the same definition should be independent: changes to "
279- "one should not affect the others. This means that all state should be "
280- "specific to the module object (using e.g. using :c:func:"
281- "`PyModule_GetState`), or its contents (such as the module's :attr:`~object."
282- "__dict__` or individual classes created with :c:func:`PyType_FromSpec`)."
275+ "not singletons. For example, if the :py:attr:`sys.modules` entry is removed "
276+ "and the module is re-imported, a new module object is created, and typically "
277+ "populated with fresh method and type objects. The old module is subject to "
278+ "normal garbage collection. This mirrors the behavior of pure-Python modules."
279+ msgstr ""
280+
281+ msgid ""
282+ "Additional module instances may be created in :ref:`sub-interpreters <sub-"
283+ "interpreter-support>` or after after Python runtime reinitialization (:c:"
284+ "func:`Py_Finalize` and :c:func:`Py_Initialize`). In these cases, sharing "
285+ "Python objects between module instances would likely cause crashes or "
286+ "undefined behavior."
287+ msgstr ""
288+
289+ msgid ""
290+ "To avoid such issues, each instance of an extension module should be "
291+ "*isolated*: changes to one instance should not implicitly affect the others, "
292+ "and all state, including references to Python objects, should be specific to "
293+ "a particular module instance. See :ref:`isolating-extensions-howto` for more "
294+ "details and a practical guide."
295+ msgstr ""
296+
297+ msgid ""
298+ "A simpler way to avoid these issues is :ref:`raising an error on repeated "
299+ "initialization <isolating-extensions-optout>`."
283300msgstr ""
284301
285302msgid ""
286303"All modules created using multi-phase initialization are expected to "
287- "support :ref:`sub-interpreters <sub-interpreter-support>`. Making sure "
288- "multiple modules are independent is typically enough to achieve this."
304+ "support :ref:`sub-interpreters <sub-interpreter-support>`, or otherwise "
305+ "explicitly signal a lack of support. This is usually achieved by isolation "
306+ "or blocking repeated initialization, as above. A module may also be limited "
307+ "to the main interpreter using the :c:data:`Py_mod_multiple_interpreters` "
308+ "slot."
289309msgstr ""
290310
291311msgid ""
0 commit comments