|
| 1 | +# SOME DESCRIPTIVE TITLE. |
| 2 | +# Copyright (C) 2001 Python Software Foundation |
| 3 | +# This file is distributed under the same license as the Python package. |
| 4 | +# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. |
| 5 | +# |
| 6 | +#, fuzzy |
| 7 | +msgid "" |
| 8 | +msgstr "" |
| 9 | +"Project-Id-Version: Python 3.14\n" |
| 10 | +"Report-Msgid-Bugs-To: \n" |
| 11 | +"POT-Creation-Date: 2025-06-20 14:21+0000\n" |
| 12 | +"PO-Revision-Date: 2025-06-20 14:22+0000\n" |
| 13 | +"Language-Team: German (https://app.transifex.com/python-doc/teams/5390/de/)\n" |
| 14 | +"MIME-Version: 1.0\n" |
| 15 | +"Content-Type: text/plain; charset=UTF-8\n" |
| 16 | +"Content-Transfer-Encoding: 8bit\n" |
| 17 | +"Language: de\n" |
| 18 | +"Plural-Forms: nplurals=2; plural=(n != 1);\n" |
| 19 | + |
| 20 | +msgid "Defining extension modules" |
| 21 | +msgstr "" |
| 22 | + |
| 23 | +msgid "" |
| 24 | +"A C extension for CPython is a shared library (for example, a ``.so`` file " |
| 25 | +"on Linux, ``.pyd`` DLL on Windows), which is loadable into the Python " |
| 26 | +"process (for example, it is compiled with compatible compiler settings), and " |
| 27 | +"which exports an :ref:`initialization function <extension-export-hook>`." |
| 28 | +msgstr "" |
| 29 | + |
| 30 | +msgid "" |
| 31 | +"To be importable by default (that is, by :py:class:`importlib.machinery." |
| 32 | +"ExtensionFileLoader`), the shared library must be available on :py:attr:`sys." |
| 33 | +"path`, and must be named after the module name plus an extension listed in :" |
| 34 | +"py:attr:`importlib.machinery.EXTENSION_SUFFIXES`." |
| 35 | +msgstr "" |
| 36 | + |
| 37 | +msgid "" |
| 38 | +"Building, packaging and distributing extension modules is best done with " |
| 39 | +"third-party tools, and is out of scope of this document. One suitable tool " |
| 40 | +"is Setuptools, whose documentation can be found at https://setuptools.pypa." |
| 41 | +"io/en/latest/setuptools.html." |
| 42 | +msgstr "" |
| 43 | + |
| 44 | +msgid "" |
| 45 | +"Normally, the initialization function returns a module definition " |
| 46 | +"initialized using :c:func:`PyModuleDef_Init`. This allows splitting the " |
| 47 | +"creation process into several phases:" |
| 48 | +msgstr "" |
| 49 | + |
| 50 | +msgid "" |
| 51 | +"Before any substantial code is executed, Python can determine which " |
| 52 | +"capabilities the module supports, and it can adjust the environment or " |
| 53 | +"refuse loading an incompatible extension." |
| 54 | +msgstr "" |
| 55 | + |
| 56 | +msgid "" |
| 57 | +"By default, Python itself creates the module object -- that is, it does the " |
| 58 | +"equivalent of :py:meth:`object.__new__` for classes. It also sets initial " |
| 59 | +"attributes like :attr:`~module.__package__` and :attr:`~module.__loader__`." |
| 60 | +msgstr "" |
| 61 | + |
| 62 | +msgid "" |
| 63 | +"Afterwards, the module object is initialized using extension-specific code " |
| 64 | +"-- the equivalent of :py:meth:`~object.__init__` on classes." |
| 65 | +msgstr "" |
| 66 | + |
| 67 | +msgid "" |
| 68 | +"This is called *multi-phase initialization* to distinguish it from the " |
| 69 | +"legacy (but still supported) *single-phase initialization* scheme, where the " |
| 70 | +"initialization function returns a fully constructed module. See the :ref:" |
| 71 | +"`single-phase-initialization section below <single-phase-initialization>` " |
| 72 | +"for details." |
| 73 | +msgstr "" |
| 74 | + |
| 75 | +msgid "Added support for multi-phase initialization (:pep:`489`)." |
| 76 | +msgstr "" |
| 77 | + |
| 78 | +msgid "Multiple module instances" |
| 79 | +msgstr "" |
| 80 | + |
| 81 | +msgid "" |
| 82 | +"By default, extension modules are not singletons. For example, if the :py:" |
| 83 | +"attr:`sys.modules` entry is removed and the module is re-imported, a new " |
| 84 | +"module object is created, and typically populated with fresh method and type " |
| 85 | +"objects. The old module is subject to normal garbage collection. This " |
| 86 | +"mirrors the behavior of pure-Python modules." |
| 87 | +msgstr "" |
| 88 | + |
| 89 | +msgid "" |
| 90 | +"Additional module instances may be created in :ref:`sub-interpreters <sub-" |
| 91 | +"interpreter-support>` or after Python runtime reinitialization (:c:func:" |
| 92 | +"`Py_Finalize` and :c:func:`Py_Initialize`). In these cases, sharing Python " |
| 93 | +"objects between module instances would likely cause crashes or undefined " |
| 94 | +"behavior." |
| 95 | +msgstr "" |
| 96 | + |
| 97 | +msgid "" |
| 98 | +"To avoid such issues, each instance of an extension module should be " |
| 99 | +"*isolated*: changes to one instance should not implicitly affect the others, " |
| 100 | +"and all state owned by the module, including references to Python objects, " |
| 101 | +"should be specific to a particular module instance. See :ref:`isolating-" |
| 102 | +"extensions-howto` for more details and a practical guide." |
| 103 | +msgstr "" |
| 104 | + |
| 105 | +msgid "" |
| 106 | +"A simpler way to avoid these issues is :ref:`raising an error on repeated " |
| 107 | +"initialization <isolating-extensions-optout>`." |
| 108 | +msgstr "" |
| 109 | + |
| 110 | +msgid "" |
| 111 | +"All modules are expected to support :ref:`sub-interpreters <sub-interpreter-" |
| 112 | +"support>`, or otherwise explicitly signal a lack of support. This is usually " |
| 113 | +"achieved by isolation or blocking repeated initialization, as above. A " |
| 114 | +"module may also be limited to the main interpreter using the :c:data:" |
| 115 | +"`Py_mod_multiple_interpreters` slot." |
| 116 | +msgstr "" |
| 117 | + |
| 118 | +msgid "Initialization function" |
| 119 | +msgstr "" |
| 120 | + |
| 121 | +msgid "" |
| 122 | +"The initialization function defined by an extension module has the following " |
| 123 | +"signature:" |
| 124 | +msgstr "" |
| 125 | + |
| 126 | +msgid "" |
| 127 | +"Its name should be :samp:`PyInit_{<name>}`, with ``<name>`` replaced by the " |
| 128 | +"name of the module." |
| 129 | +msgstr "" |
| 130 | + |
| 131 | +msgid "" |
| 132 | +"For modules with ASCII-only names, the function must instead be named :samp:" |
| 133 | +"`PyInit_{<name>}`, with ``<name>`` replaced by the name of the module. When " |
| 134 | +"using :ref:`multi-phase-initialization`, non-ASCII module names are allowed. " |
| 135 | +"In this case, the initialization function name is :samp:`PyInitU_{<name>}`, " |
| 136 | +"with ``<name>`` encoded using Python's *punycode* encoding with hyphens " |
| 137 | +"replaced by underscores. In Python:" |
| 138 | +msgstr "" |
| 139 | + |
| 140 | +msgid "" |
| 141 | +"def initfunc_name(name):\n" |
| 142 | +" try:\n" |
| 143 | +" suffix = b'_' + name.encode('ascii')\n" |
| 144 | +" except UnicodeEncodeError:\n" |
| 145 | +" suffix = b'U_' + name.encode('punycode').replace(b'-', b'_')\n" |
| 146 | +" return b'PyInit' + suffix" |
| 147 | +msgstr "" |
| 148 | + |
| 149 | +msgid "" |
| 150 | +"It is recommended to define the initialization function using a helper macro:" |
| 151 | +msgstr "" |
| 152 | + |
| 153 | +msgid "Declare an extension module initialization function. This macro:" |
| 154 | +msgstr "" |
| 155 | + |
| 156 | +msgid "specifies the :c:expr:`PyObject*` return type," |
| 157 | +msgstr "" |
| 158 | + |
| 159 | +msgid "adds any special linkage declarations required by the platform, and" |
| 160 | +msgstr "" |
| 161 | + |
| 162 | +msgid "for C++, declares the function as ``extern \"C\"``." |
| 163 | +msgstr "" |
| 164 | + |
| 165 | +msgid "For example, a module called ``spam`` would be defined like this::" |
| 166 | +msgstr "" |
| 167 | + |
| 168 | +msgid "" |
| 169 | +"static struct PyModuleDef spam_module = {\n" |
| 170 | +" .m_base = PyModuleDef_HEAD_INIT,\n" |
| 171 | +" .m_name = \"spam\",\n" |
| 172 | +" ...\n" |
| 173 | +"};\n" |
| 174 | +"\n" |
| 175 | +"PyMODINIT_FUNC\n" |
| 176 | +"PyInit_spam(void)\n" |
| 177 | +"{\n" |
| 178 | +" return PyModuleDef_Init(&spam_module);\n" |
| 179 | +"}" |
| 180 | +msgstr "" |
| 181 | + |
| 182 | +msgid "" |
| 183 | +"It is possible to export multiple modules from a single shared library by " |
| 184 | +"defining multiple initialization functions. However, importing them requires " |
| 185 | +"using symbolic links or a custom importer, because by default only the " |
| 186 | +"function corresponding to the filename is found. See the `Multiple modules " |
| 187 | +"in one library <https://peps.python.org/pep-0489/#multiple-modules-in-one-" |
| 188 | +"library>`__ section in :pep:`489` for details." |
| 189 | +msgstr "" |
| 190 | + |
| 191 | +msgid "" |
| 192 | +"The initialization function is typically the only non-\\ ``static`` item " |
| 193 | +"defined in the module's C source." |
| 194 | +msgstr "" |
| 195 | + |
| 196 | +msgid "Multi-phase initialization" |
| 197 | +msgstr "" |
| 198 | + |
| 199 | +msgid "" |
| 200 | +"Normally, the :ref:`initialization function <extension-export-hook>` " |
| 201 | +"(``PyInit_modulename``) returns a :c:type:`PyModuleDef` instance with non-" |
| 202 | +"``NULL`` :c:member:`~PyModuleDef.m_slots`. Before it is returned, the " |
| 203 | +"``PyModuleDef`` instance must be initialized using the following function:" |
| 204 | +msgstr "" |
| 205 | + |
| 206 | +msgid "" |
| 207 | +"Ensure a module definition is a properly initialized Python object that " |
| 208 | +"correctly reports its type and a reference count." |
| 209 | +msgstr "" |
| 210 | + |
| 211 | +msgid "Return *def* cast to ``PyObject*``, or ``NULL`` if an error occurred." |
| 212 | +msgstr "" |
| 213 | + |
| 214 | +msgid "" |
| 215 | +"Calling this function is required for :ref:`multi-phase-initialization`. It " |
| 216 | +"should not be used in other contexts." |
| 217 | +msgstr "" |
| 218 | + |
| 219 | +msgid "" |
| 220 | +"Note that Python assumes that ``PyModuleDef`` structures are statically " |
| 221 | +"allocated. This function may return either a new reference or a borrowed " |
| 222 | +"one; this reference must not be released." |
| 223 | +msgstr "" |
| 224 | + |
| 225 | +msgid "Legacy single-phase initialization" |
| 226 | +msgstr "" |
| 227 | + |
| 228 | +msgid "" |
| 229 | +"Single-phase initialization is a legacy mechanism to initialize extension " |
| 230 | +"modules, with known drawbacks and design flaws. Extension module authors are " |
| 231 | +"encouraged to use multi-phase initialization instead." |
| 232 | +msgstr "" |
| 233 | + |
| 234 | +msgid "" |
| 235 | +"In single-phase initialization, the :ref:`initialization function <extension-" |
| 236 | +"export-hook>` (``PyInit_modulename``) should create, populate and return a " |
| 237 | +"module object. This is typically done using :c:func:`PyModule_Create` and " |
| 238 | +"functions like :c:func:`PyModule_AddObjectRef`." |
| 239 | +msgstr "" |
| 240 | + |
| 241 | +msgid "" |
| 242 | +"Single-phase initialization differs from the :ref:`default <multi-phase-" |
| 243 | +"initialization>` in the following ways:" |
| 244 | +msgstr "" |
| 245 | + |
| 246 | +msgid "Single-phase modules are, or rather *contain*, “singletons”." |
| 247 | +msgstr "" |
| 248 | + |
| 249 | +msgid "" |
| 250 | +"When the module is first initialized, Python saves the contents of the " |
| 251 | +"module's ``__dict__`` (that is, typically, the module's functions and types)." |
| 252 | +msgstr "" |
| 253 | + |
| 254 | +msgid "" |
| 255 | +"For subsequent imports, Python does not call the initialization function " |
| 256 | +"again. Instead, it creates a new module object with a new ``__dict__``, and " |
| 257 | +"copies the saved contents to it. For example, given a single-phase module " |
| 258 | +"``_testsinglephase`` [#testsinglephase]_ that defines a function ``sum`` and " |
| 259 | +"an exception class ``error``:" |
| 260 | +msgstr "" |
| 261 | + |
| 262 | +msgid "" |
| 263 | +">>> import sys\n" |
| 264 | +">>> import _testsinglephase as one\n" |
| 265 | +">>> del sys.modules['_testsinglephase']\n" |
| 266 | +">>> import _testsinglephase as two\n" |
| 267 | +">>> one is two\n" |
| 268 | +"False\n" |
| 269 | +">>> one.__dict__ is two.__dict__\n" |
| 270 | +"False\n" |
| 271 | +">>> one.sum is two.sum\n" |
| 272 | +"True\n" |
| 273 | +">>> one.error is two.error\n" |
| 274 | +"True" |
| 275 | +msgstr "" |
| 276 | + |
| 277 | +msgid "" |
| 278 | +"The exact behavior should be considered a CPython implementation detail." |
| 279 | +msgstr "" |
| 280 | + |
| 281 | +msgid "" |
| 282 | +"To work around the fact that ``PyInit_modulename`` does not take a *spec* " |
| 283 | +"argument, some state of the import machinery is saved and applied to the " |
| 284 | +"first suitable module created during the ``PyInit_modulename`` call. " |
| 285 | +"Specifically, when a sub-module is imported, this mechanism prepends the " |
| 286 | +"parent package name to the name of the module." |
| 287 | +msgstr "" |
| 288 | + |
| 289 | +msgid "" |
| 290 | +"A single-phase ``PyInit_modulename`` function should create “its” module " |
| 291 | +"object as soon as possible, before any other module objects can be created." |
| 292 | +msgstr "" |
| 293 | + |
| 294 | +msgid "Non-ASCII module names (``PyInitU_modulename``) are not supported." |
| 295 | +msgstr "" |
| 296 | + |
| 297 | +msgid "" |
| 298 | +"Single-phase modules support module lookup functions like :c:func:" |
| 299 | +"`PyState_FindModule`." |
| 300 | +msgstr "" |
| 301 | + |
| 302 | +msgid "" |
| 303 | +"``_testsinglephase`` is an internal module used \\ in CPython's self-test " |
| 304 | +"suite; your installation may or may not \\ include it." |
| 305 | +msgstr "" |
0 commit comments