# 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:

# python-doc bot, 2025

#

#, fuzzy

msgid ""

msgstr ""

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

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

"POT-Creation-Date: 2026-08-22 12:07+0200\n"

"PO-Revision-Date: 2025-09-16 00:02+0000\n"

"Last-Translator: python-doc bot, 2025\n"

"Language-Team: German (https://app.transifex.com/python-doc/teams/5390/de/)\n"

"Language: de\n"

"MIME-Version: 1.0\n"

"Content-Type: text/plain; charset=UTF-8\n"

"Content-Transfer-Encoding: 8bit\n"

"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#: ../../reference/import.rst:6

msgid "The import system"

msgstr ""

#: ../../reference/import.rst:10

msgid ""

"Python code in one :term:`module` gains access to the code in another module "

"by the process of :term:`importing` it. The :keyword:`import` statement is "

"the most common way of invoking the import machinery, but it is not the only "

"way. Functions such as :func:`importlib.import_module` and built-in :func:"

"`__import__` can also be used to invoke the import machinery."

msgstr ""

#: ../../reference/import.rst:16

msgid ""

"The :keyword:`import` statement combines two operations; it searches for the "

"named module, then it binds the results of that search to a name in the "

"local scope. The search operation of the :keyword:`!import` statement is "

"defined as a call to the :func:`__import__` function, with the appropriate "

"arguments. The return value of :func:`__import__` is used to perform the "

"name binding operation of the :keyword:`!import` statement. See the :"

"keyword:`!import` statement for the exact details of that name binding "

"operation."

msgstr ""

#: ../../reference/import.rst:25

msgid ""

"A direct call to :func:`__import__` performs only the module search and, if "

"found, the module creation operation. While certain side-effects may occur, "

"such as the importing of parent packages, and the updating of various caches "

"(including :data:`sys.modules`), only the :keyword:`import` statement "

"performs a name binding operation."

msgstr ""

#: ../../reference/import.rst:31

msgid ""

"When an :keyword:`import` statement is executed, the standard builtin :func:"

"`__import__` function is called. Other mechanisms for invoking the import "

"system (such as :func:`importlib.import_module`) may choose to bypass :func:"

"`__import__` and use their own solutions to implement import semantics."

msgstr ""

#: ../../reference/import.rst:36

msgid ""

"When a module is first imported, Python searches for the module and if "

"found, it creates a module object [#fnmo]_, initializing it. If the named "

"module cannot be found, a :exc:`ModuleNotFoundError` is raised. Python "

"implements various strategies to search for the named module when the import "

"machinery is invoked. These strategies can be modified and extended by "

"using various hooks described in the sections below."

msgstr ""

#: ../../reference/import.rst:43

msgid ""

"The import system has been updated to fully implement the second phase of :"

"pep:`302`. There is no longer any implicit import machinery - the full "

"import system is exposed through :data:`sys.meta_path`. In addition, native "

"namespace package support has been implemented (see :pep:`420`)."

msgstr ""

#: ../../reference/import.rst:51

msgid ":mod:`importlib`"

msgstr ""

#: ../../reference/import.rst:53

msgid ""

"The :mod:`importlib` module provides a rich API for interacting with the "

"import system. For example :func:`importlib.import_module` provides a "

"recommended, simpler API than built-in :func:`__import__` for invoking the "

"import machinery. Refer to the :mod:`importlib` library documentation for "

"additional detail."

msgstr ""

#: ../../reference/import.rst:62

msgid "Packages"

msgstr ""

#: ../../reference/import.rst:67

msgid ""

"Python has only one type of module object, and all modules are of this type, "

"regardless of whether the module is implemented in Python, C, or something "

"else. To help organize modules and provide a naming hierarchy, Python has a "

"concept of :term:`packages <package>`."

msgstr ""

#: ../../reference/import.rst:72

msgid ""

"You can think of packages as the directories on a file system and modules as "

"files within directories, but don't take this analogy too literally since "

"packages and modules need not originate from the file system. For the "

"purposes of this documentation, we'll use this convenient analogy of "

"directories and files. Like file system directories, packages are organized "

"hierarchically, and packages may themselves contain subpackages, as well as "

"regular modules."

msgstr ""

#: ../../reference/import.rst:80

msgid ""

"It's important to keep in mind that all packages are modules, but not all "

"modules are packages. Or put another way, packages are just a special kind "

"of module. Specifically, any module that contains a ``__path__`` attribute "

"is considered a package."

msgstr ""

#: ../../reference/import.rst:85

msgid ""

"All modules have a name. Subpackage names are separated from their parent "

"package name by a dot, akin to Python's standard attribute access syntax. "

"Thus you might have a package called :mod:`email`, which in turn has a "

"subpackage called :mod:`email.mime` and a module within that subpackage "

"called :mod:`email.mime.text`."

msgstr ""

#: ../../reference/import.rst:93

msgid "Regular packages"

msgstr ""

#: ../../reference/import.rst:98

msgid ""

"Python defines two types of packages, :term:`regular packages <regular "

"package>` and :term:`namespace packages <namespace package>`. Regular "

"packages are traditional packages as they existed in Python 3.2 and earlier. "

"A regular package is typically implemented as a directory containing an "

"``__init__.py`` file. When a regular package is imported, this ``__init__."

"py`` file is implicitly executed, and the objects it defines are bound to "

"names in the package's namespace. The ``__init__.py`` file can contain the "

"same Python code that any other module can contain, and Python will add some "

"additional attributes to the module when it is imported."

msgstr ""

#: ../../reference/import.rst:108

msgid ""

"For example, the following file system layout defines a top level ``parent`` "

"package with three subpackages::"

msgstr ""

#: ../../reference/import.rst:111

msgid ""

"parent/\n"

" __init__.py\n"

" one/\n"

" __init__.py\n"

" two/\n"

" __init__.py\n"

" three/\n"

" __init__.py"

msgstr ""

#: ../../reference/import.rst:120

msgid ""

"Importing ``parent.one`` will implicitly execute ``parent/__init__.py`` and "

"``parent/one/__init__.py``. Subsequent imports of ``parent.two`` or "

"``parent.three`` will execute ``parent/two/__init__.py`` and ``parent/three/"

"__init__.py`` respectively."

msgstr ""

#: ../../reference/import.rst:125

msgid ""

"A subdirectory inside a regular package that does not contain an ``__init__."

"py`` file is treated as an implicit :ref:`namespace package <reference-"

"namespace-package>` (a \"namespace subpackage\") rooted in that parent. "

"See :pep:`420` for the underlying specification."

msgstr ""

#: ../../reference/import.rst:135

msgid "Namespace packages"

msgstr ""

#: ../../reference/import.rst:141

msgid ""

"A namespace package is a composite of various :term:`portions <portion>`, "

"where each portion contributes a subpackage to the parent package. Portions "

"may reside in different locations on the file system. Portions may also be "

"found in zip files, on the network, or anywhere else that Python searches "

"during import. Namespace packages may or may not correspond directly to "

"objects on the file system; they may be virtual modules that have no "

"concrete representation."

msgstr ""

#: ../../reference/import.rst:149

msgid ""

"Namespace packages do not use an ordinary list for their ``__path__`` "

"attribute. They instead use a custom iterable type which will automatically "

"perform a new search for package portions on the next import attempt within "

"that package if the path of their parent package (or :data:`sys.path` for a "

"top level package) changes."

msgstr ""

#: ../../reference/import.rst:155

msgid ""

"With namespace packages, there is no ``parent/__init__.py`` file. In fact, "

"there may be multiple ``parent`` directories found during import search, "

"where each one is provided by a different portion. Thus ``parent/one`` may "

"not be physically located next to ``parent/two``. In this case, Python will "

"create a namespace package for the top-level ``parent`` package whenever it "

"or one of its subpackages is imported."

msgstr ""

#: ../../reference/import.rst:162

msgid ""

"Namespace packages may also be nested inside a regular package. When the "

"import system searches a regular package's ``__path__`` and encounters a "

"subdirectory that does not contain an ``__init__.py`` file, that "

"subdirectory becomes a :term:`portion` contributing to a namespace "

"subpackage of the enclosing regular package."

msgstr ""

#: ../../reference/import.rst:168

msgid "See also :pep:`420` for the namespace package specification."

msgstr ""

#: ../../reference/import.rst:172

msgid "Searching"

msgstr ""

#: ../../reference/import.rst:174

msgid ""

"To begin the search, Python needs the :term:`fully qualified <qualified "

"name>` name of the module (or package, but for the purposes of this "

"discussion, the difference is immaterial) being imported. This name may "

"come from various arguments to the :keyword:`import` statement, or from the "

"parameters to the :func:`importlib.import_module` or :func:`__import__` "

"functions."

msgstr ""

#: ../../reference/import.rst:180

msgid ""

"This name will be used in various phases of the import search, and it may be "

"the dotted path to a submodule, e.g. ``foo.bar.baz``. In this case, Python "

"first tries to import ``foo``, then ``foo.bar``, and finally ``foo.bar."

"baz``. If any of the intermediate imports fail, a :exc:`ModuleNotFoundError` "

"is raised."

msgstr ""

#: ../../reference/import.rst:187

msgid "The module cache"

msgstr ""

#: ../../reference/import.rst:192

msgid ""

"The first place checked during import search is :data:`sys.modules`. This "

"mapping serves as a cache of all modules that have been previously imported, "

"including the intermediate paths. So if ``foo.bar.baz`` was previously "

"imported, :data:`sys.modules` will contain entries for ``foo``, ``foo.bar``, "

"and ``foo.bar.baz``. Each key will have as its value the corresponding "

"module object."

msgstr ""

#: ../../reference/import.rst:199

msgid ""

"During import, the module name is looked up in :data:`sys.modules` and if "

"present, the associated value is the module satisfying the import, and the "

"process completes. However, if the value is ``None``, then a :exc:"

"`ModuleNotFoundError` is raised. If the module name is missing, Python will "

"continue searching for the module."

msgstr ""

#: ../../reference/import.rst:205

msgid ""

":data:`sys.modules` is writable. Deleting a key may not destroy the "

"associated module (as other modules may hold references to it), but it will "

"invalidate the cache entry for the named module, causing Python to search "

"anew for the named module upon its next import. The key can also be assigned "

"to ``None``, forcing the next import of the module to result in a :exc:"

"`ModuleNotFoundError`."

msgstr ""

#: ../../reference/import.rst:212

msgid ""

"Beware though, as if you keep a reference to the module object, invalidate "

"its cache entry in :data:`sys.modules`, and then re-import the named module, "

"the two module objects will *not* be the same. By contrast, :func:`importlib."

"reload` will reuse the *same* module object, and simply reinitialise the "

"module contents by rerunning the module's code."

msgstr ""

#: ../../reference/import.rst:222

msgid "Finders and loaders"

msgstr ""

#: ../../reference/import.rst:229

msgid ""

"If the named module is not found in :data:`sys.modules`, then Python's "

"import protocol is invoked to find and load the module. This protocol "

"consists of two conceptual objects, :term:`finders <finder>` and :term:"

"`loaders <loader>`. A finder's job is to determine whether it can find the "

"named module using whatever strategy it knows about. Objects that implement "

"both of these interfaces are referred to as :term:`importers <importer>` - "

"they return themselves when they find that they can load the requested "

"module."

msgstr ""

#: ../../reference/import.rst:237

msgid ""

"Python includes a number of default finders and importers. The first one "

"knows how to locate built-in modules, and the second knows how to locate "

"frozen modules. A third default finder searches an :term:`import path` for "

"modules. The :term:`import path` is a list of locations that may name file "

"system paths or zip files. It can also be extended to search for any "

"locatable resource, such as those identified by URLs."

msgstr ""

#: ../../reference/import.rst:244

msgid ""

"The import machinery is extensible, so new finders can be added to extend "

"the range and scope of module searching."

msgstr ""

#: ../../reference/import.rst:247

msgid ""

"Finders do not actually load modules. If they can find the named module, "

"they return a :dfn:`module spec`, an encapsulation of the module's import-"

"related information, which the import machinery then uses when loading the "

"module."

msgstr ""

#: ../../reference/import.rst:251

msgid ""

"The following sections describe the protocol for finders and loaders in more "

"detail, including how you can create and register new ones to extend the "

"import machinery."

msgstr ""

#: ../../reference/import.rst:255

msgid ""

"In previous versions of Python, finders returned :term:`loaders <loader>` "

"directly, whereas now they return module specs which *contain* loaders. "

"Loaders are still used during import but have fewer responsibilities."

msgstr ""

#: ../../reference/import.rst:261

msgid "Import hooks"

msgstr ""

#: ../../reference/import.rst:271

msgid ""

"The import machinery is designed to be extensible; the primary mechanism for "

"this are the *import hooks*. There are two types of import hooks: *meta "

"hooks* and *import path hooks*."

msgstr ""

#: ../../reference/import.rst:275

msgid ""

"Meta hooks are called at the start of import processing, before any other "

"import processing has occurred, other than :data:`sys.modules` cache look "

"up. This allows meta hooks to override :data:`sys.path` processing, frozen "

"modules, or even built-in modules. Meta hooks are registered by adding new "

"finder objects to :data:`sys.meta_path`, as described below."

msgstr ""

#: ../../reference/import.rst:281

msgid ""

"Import path hooks are called as part of :data:`sys.path` (or ``package."

"__path__``) processing, at the point where their associated path item is "

"encountered. Import path hooks are registered by adding new callables to :"

"data:`sys.path_hooks` as described below."

msgstr ""

#: ../../reference/import.rst:288

msgid "The meta path"

msgstr ""

#: ../../reference/import.rst:294

msgid ""

"When the named module is not found in :data:`sys.modules`, Python next "

"searches :data:`sys.meta_path`, which contains a list of meta path finder "

"objects. These finders are queried in order to see if they know how to "

"handle the named module. Meta path finders must implement a method called :"

"meth:`~importlib.abc.MetaPathFinder.find_spec` which takes three arguments: "

"a name, an import path, and (optionally) a target module. The meta path "

"finder can use any strategy it wants to determine whether it can handle the "

"named module or not."

msgstr ""

#: ../../reference/import.rst:303

msgid ""

"If the meta path finder knows how to handle the named module, it returns a "

"spec object. If it cannot handle the named module, it returns ``None``. "

"If :data:`sys.meta_path` processing reaches the end of its list without "

"returning a spec, then a :exc:`ModuleNotFoundError` is raised. Any other "

"exceptions raised are simply propagated up, aborting the import process."

msgstr ""

#: ../../reference/import.rst:309

msgid ""

"The :meth:`~importlib.abc.MetaPathFinder.find_spec` method of meta path "

"finders is called with two or three arguments. The first is the fully "

"qualified name of the module being imported, for example ``foo.bar.baz``. "

"The second argument is the path entries to use for the module search. For "

"top-level modules, the second argument is ``None``, but for submodules or "

"subpackages, the second argument is the value of the parent package's "

"``__path__`` attribute. If the appropriate ``__path__`` attribute cannot be "

"accessed, a :exc:`ModuleNotFoundError` is raised. The third argument is an "

"existing module object that will be the target of loading later. The import "

"system passes in a target module only during reload."

msgstr ""

#: ../../reference/import.rst:320

msgid ""

"The meta path may be traversed multiple times for a single import request. "

"For example, assuming none of the modules involved has already been cached, "

"importing ``foo.bar.baz`` will first perform a top level import, calling "

"``mpf.find_spec(\"foo\", None, None)`` on each meta path finder (``mpf``). "

"After ``foo`` has been imported, ``foo.bar`` will be imported by traversing "

"the meta path a second time, calling ``mpf.find_spec(\"foo.bar\", foo."

"__path__, None)``. Once ``foo.bar`` has been imported, the final traversal "

"will call ``mpf.find_spec(\"foo.bar.baz\", foo.bar.__path__, None)``."

msgstr ""

#: ../../reference/import.rst:330

msgid ""

"Some meta path finders only support top level imports. These importers will "

"always return ``None`` when anything other than ``None`` is passed as the "

"second argument."

msgstr ""

#: ../../reference/import.rst:334

msgid ""

"Python's default :data:`sys.meta_path` has three meta path finders, one that "

"knows how to import built-in modules, one that knows how to import frozen "

"modules, and one that knows how to import modules from an :term:`import "

"path` (i.e. the :term:`path based finder`)."

msgstr ""

#: ../../reference/import.rst:339

msgid ""

"The :meth:`~importlib.abc.MetaPathFinder.find_spec` method of meta path "

"finders replaced :meth:`!find_module`, which is now deprecated. While it "

"will continue to work without change, the import machinery will try it only "

"if the finder does not implement :meth:`~importlib.abc.MetaPathFinder."

"find_spec`."

msgstr ""

#: ../../reference/import.rst:346

msgid ""

"Use of :meth:`!find_module` by the import system now raises :exc:"

"`ImportWarning`."

msgstr ""

#: ../../reference/import.rst:350

msgid ""

":meth:`!find_module` has been removed. Use :meth:`~importlib.abc."

"MetaPathFinder.find_spec` instead."

msgstr ""

#: ../../reference/import.rst:356

msgid "Loading"

msgstr ""

#: ../../reference/import.rst:358

msgid ""

"If and when a module spec is found, the import machinery will use it (and "

"the loader it contains) when loading the module. Here is an approximation "

"of what happens during the loading portion of import::"

msgstr ""

#: ../../reference/import.rst:362

msgid ""

"module = None\n"

"if spec.loader is not None and hasattr(spec.loader, 'create_module'):\n"

" # It is assumed 'exec_module' will also be defined on the loader.\n"

" module = spec.loader.create_module(spec)\n"

"if module is None:\n"

" module = ModuleType(spec.name)\n"

"# The import-related module attributes get set here:\n"

"_init_module_attrs(spec, module)\n"

"\n"

"if spec.loader is None:\n"

" # unsupported\n"

" raise ImportError\n"

"\n"

"sys.modules[spec.name] = module\n"

"try:\n"

" spec.loader.exec_module(module)\n"

"except BaseException:\n"

" try:\n"

" del sys.modules[spec.name]\n"

" except KeyError:\n"

" pass\n"

" raise\n"

"return sys.modules[spec.name]"

msgstr ""

#: ../../reference/import.rst:386

msgid "Note the following details:"

msgstr ""

#: ../../reference/import.rst:388

msgid ""

"If there is an existing module object with the given name in :data:`sys."

"modules`, import will have already returned it."

msgstr ""

#: ../../reference/import.rst:391

msgid ""

"The module will exist in :data:`sys.modules` before the loader executes the "

"module code. This is crucial because the module code may (directly or "

"indirectly) import itself; adding it to :data:`sys.modules` beforehand "

"prevents unbounded recursion in the worst case and multiple loading in the "

"best."

msgstr ""

#: ../../reference/import.rst:397

msgid ""

"If loading fails, the failing module -- and only the failing module -- gets "

"removed from :data:`sys.modules`. Any module already in the :data:`sys."

"modules` cache, and any module that was successfully loaded as a side-"

"effect, must remain in the cache. This contrasts with reloading where even "

"the failing module is left in :data:`sys.modules`."

msgstr ""

#: ../../reference/import.rst:403

msgid ""

"After the module is created but before execution, the import machinery sets "

"the import-related module attributes (\"_init_module_attrs\" in the pseudo-"

"code example above), as summarized in a :ref:`later section <import-mod-"

"attrs>`."

msgstr ""

#: ../../reference/import.rst:408

msgid ""

"Module execution is the key moment of loading in which the module's "

"namespace gets populated. Execution is entirely delegated to the loader, "

"which gets to decide what gets populated and how."

msgstr ""

#: ../../reference/import.rst:412

msgid ""

"The module created during loading and passed to exec_module() may not be the "

"one returned at the end of import [#fnlo]_."

msgstr ""

#: ../../reference/import.rst:415

msgid ""

"The import system has taken over the boilerplate responsibilities of "

"loaders. These were previously performed by the ``importlib.abc.Loader."

"load_module`` method."

msgstr ""

#: ../../reference/import.rst:420

msgid "The ``load_module`` method is no longer used."

msgstr ""

#: ../../reference/import.rst:424

msgid "Loaders"

msgstr ""

#: ../../reference/import.rst:426

msgid ""

"Module loaders provide the critical function of loading: module execution. "

"The import machinery calls the :meth:`importlib.abc.Loader.exec_module` "

"method with a single argument, the module object to execute. Any value "

"returned from :meth:`~importlib.abc.Loader.exec_module` is ignored."

msgstr ""

#: ../../reference/import.rst:431

msgid "Loaders must satisfy the following requirements:"

msgstr ""

#: ../../reference/import.rst:433

msgid ""

"If the module is a Python module (as opposed to a built-in module or a "

"dynamically loaded extension), the loader should execute the module's code "

"in the module's global name space (``module.__dict__``)."

msgstr ""

#: ../../reference/import.rst:437

msgid ""

"If the loader cannot execute the module, it should raise an :exc:"

"`ImportError`, although any other exception raised during :meth:`~importlib."

"abc.Loader.exec_module` will be propagated."

msgstr ""

#: ../../reference/import.rst:441

msgid ""

"In many cases, the finder and loader can be the same object; in such cases "

"the :meth:`~importlib.abc.MetaPathFinder.find_spec` method would just return "

"a spec with the loader set to ``self``."

msgstr ""

#: ../../reference/import.rst:445

msgid ""

"Module loaders may opt in to creating the module object during loading by "

"implementing a :meth:`~importlib.abc.Loader.create_module` method. It takes "

"one argument, the module spec, and returns the new module object to use "

"during loading. ``create_module()`` does not need to set any attributes on "

"the module object. If the method returns ``None``, the import machinery "

"will create the new module itself."

msgstr ""

#: ../../reference/import.rst:452

msgid "The :meth:`~importlib.abc.Loader.create_module` method of loaders."

msgstr ""

#: ../../reference/import.rst:455

msgid ""

"The ``importlib.abc.Loader.load_module`` method was replaced by :meth:"

"`~importlib.abc.Loader.exec_module` and the import machinery assumed all the "

"boilerplate responsibilities of loading."

msgstr ""

#: ../../reference/import.rst:460

msgid ""

"For compatibility with existing loaders, the import machinery will use the "

"``load_module()`` method of loaders if it exists and the loader does not "

"also implement ``exec_module()``. However, ``load_module()`` has been "

"deprecated and loaders should implement ``exec_module()`` instead."

msgstr ""

#: ../../reference/import.rst:465

msgid ""

"The ``load_module()`` method must implement all the boilerplate loading "

"functionality described above in addition to executing the module. All the "

"same constraints apply, with some additional clarification:"

msgstr ""

#: ../../reference/import.rst:469

msgid ""

"If there is an existing module object with the given name in :data:`sys."

"modules`, the loader must use that existing module. (Otherwise, :func:"

"`importlib.reload` will not work correctly.) If the named module does not "

"exist in :data:`sys.modules`, the loader must create a new module object and "

"add it to :data:`sys.modules`."

msgstr ""

#: ../../reference/import.rst:475

msgid ""

"The module *must* exist in :data:`sys.modules` before the loader executes "

"the module code, to prevent unbounded recursion or multiple loading."

msgstr ""

#: ../../reference/import.rst:479

msgid ""

"If loading fails, the loader must remove any modules it has inserted into :"

"data:`sys.modules`, but it must remove **only** the failing module(s), and "

"only if the loader itself has loaded the module(s) explicitly."

msgstr ""

#: ../../reference/import.rst:484

msgid ""

"A :exc:`DeprecationWarning` is raised when ``exec_module()`` is defined but "

"``create_module()`` is not."

msgstr ""

#: ../../reference/import.rst:488

msgid ""

"An :exc:`ImportError` is raised when ``exec_module()`` is defined but "

"``create_module()`` is not."

msgstr ""

#: ../../reference/import.rst:492

msgid "Use of ``load_module()`` will raise :exc:`ImportWarning`."

msgstr ""

#: ../../reference/import.rst:496

msgid "Submodules"

msgstr ""

#: ../../reference/import.rst:498

msgid ""

"When a submodule is loaded using any mechanism (e.g. ``importlib`` APIs, the "

"``import`` or ``import-from`` statements, or built-in ``__import__()``) a "

"binding is placed in the parent module's namespace to the submodule object. "

"For example, if package ``spam`` has a submodule ``foo``, after importing "

"``spam.foo``, ``spam`` will have an attribute ``foo`` which is bound to the "

"submodule. Let's say you have the following directory structure::"

msgstr ""

#: ../../reference/import.rst:505

msgid ""

"spam/\n"

" __init__.py\n"

" foo.py"

msgstr ""

#: ../../reference/import.rst:509

msgid "and ``spam/__init__.py`` has the following line in it::"

msgstr ""

#: ../../reference/import.rst:511

msgid "from .foo import Foo"

msgstr ""

#: ../../reference/import.rst:513

msgid ""

"then executing the following puts name bindings for ``foo`` and ``Foo`` in "

"the ``spam`` module::"

msgstr ""

#: ../../reference/import.rst:516

msgid ""

">>> import spam\n"

">>> spam.foo\n"

"<module 'spam.foo' from '/tmp/imports/spam/foo.py'>\n"

">>> spam.Foo\n"

"<class 'spam.foo.Foo'>"

msgstr ""

#: ../../reference/import.rst:522

msgid ""

"Given Python's familiar name binding rules this might seem surprising, but "

"it's actually a fundamental feature of the import system. The invariant "

"holding is that if you have ``sys.modules['spam']`` and ``sys.modules['spam."

"foo']`` (as you would after the above import), the latter must appear as the "

"``foo`` attribute of the former."

msgstr ""

#: ../../reference/import.rst:531

msgid "Module specs"

msgstr ""

#: ../../reference/import.rst:533

msgid ""

"The import machinery uses a variety of information about each module during "

"import, especially before loading. Most of the information is common to all "

"modules. The purpose of a module's spec is to encapsulate this import-"

"related information on a per-module basis."

msgstr ""

#: ../../reference/import.rst:538

msgid ""

"Using a spec during import allows state to be transferred between import "

"system components, e.g. between the finder that creates the module spec and "

"the loader that executes it. Most importantly, it allows the import "

"machinery to perform the boilerplate operations of loading, whereas without "

"a module spec the loader had that responsibility."

msgstr ""

#: ../../reference/import.rst:544

msgid ""

"The module's spec is exposed as :attr:`module.__spec__`. Setting :attr:`!"

"__spec__` appropriately applies equally to :ref:`modules initialized during "

"interpreter startup <programs>`. The one exception is ``__main__``, where :"

"attr:`!__spec__` is :ref:`set to None in some cases <main_spec>`."

msgstr ""

#: ../../reference/import.rst:550

msgid ""

"See :class:`~importlib.machinery.ModuleSpec` for details on the contents of "

"the module spec."

msgstr ""

#: ../../reference/import.rst:558

msgid "__path__ attributes on modules"

msgstr ""

#: ../../reference/import.rst:560

msgid ""

"The :attr:`~module.__path__` attribute should be a (possibly empty) :term:"

"`sequence` of strings enumerating the locations where the package's "

"submodules will be found. By definition, if a module has a :attr:`!__path__` "

"attribute, it is a :term:`package`."

msgstr ""

#: ../../reference/import.rst:565

msgid ""

"A package's :attr:`~module.__path__` attribute is used during imports of its "

"subpackages. Within the import machinery, it functions much the same as :"

"data:`sys.path`, i.e. providing a list of locations to search for modules "

"during import. However, :attr:`!__path__` is typically much more constrained "

"than :data:`!sys.path`."

msgstr ""

#: ../../reference/import.rst:572

msgid ""

"The same rules used for :data:`sys.path` also apply to a package's :attr:`!"

"__path__`. :data:`sys.path_hooks` (described below) are consulted when "

"traversing a package's :attr:`!__path__`."

msgstr ""

#: ../../reference/import.rst:576

msgid ""

"A package's ``__init__.py`` file may set or alter the package's :attr:"

"`~module.__path__` attribute, and this was typically the way namespace "

"packages were implemented prior to :pep:`420`. With the adoption of :pep:"

"`420`, namespace packages no longer need to supply ``__init__.py`` files "

"containing only :attr:`!__path__` manipulation code; the import machinery "

"automatically sets :attr:`!__path__` correctly for the namespace package."

msgstr ""

#: ../../reference/import.rst:585

msgid "Module reprs"

msgstr ""

#: ../../reference/import.rst:587

msgid ""

"By default, all modules have a usable repr, however depending on the "

"attributes set above, and in the module's spec, you can more explicitly "

"control the repr of module objects."

msgstr ""

#: ../../reference/import.rst:591

msgid ""

"If the module has a spec (``__spec__``), the import machinery will try to "

"generate a repr from it. If that fails or there is no spec, the import "

"system will craft a default repr using whatever information is available on "

"the module. It will try to use the ``module.__name__``, ``module."

"__file__``, and ``module.__loader__`` as input into the repr, with defaults "

"for whatever information is missing."

msgstr ""

#: ../../reference/import.rst:598

msgid "Here are the exact rules used:"

msgstr ""

#: ../../reference/import.rst:600

msgid ""

"If the module has a ``__spec__`` attribute, the information in the spec is "

"used to generate the repr. The \"name\", \"loader\", \"origin\", and "

"\"has_location\" attributes are consulted."

msgstr ""

#: ../../reference/import.rst:604

msgid ""

"If the module has a ``__file__`` attribute, this is used as part of the "

"module's repr."

msgstr ""

#: ../../reference/import.rst:607

msgid ""

"If the module has no ``__file__`` but does have a ``__loader__`` that is not "

"``None``, then the loader's repr is used as part of the module's repr."

msgstr ""

#: ../../reference/import.rst:610

msgid "Otherwise, just use the module's ``__name__`` in the repr."

msgstr ""

#: ../../reference/import.rst:612

msgid ""

"Use of :meth:`!module_repr`, having been deprecated since Python 3.4, was "

"removed in Python 3.12 and is no longer called during the resolution of a "

"module's repr."

msgstr ""

#: ../../reference/import.rst:620

msgid "Cached bytecode invalidation"

msgstr ""

#: ../../reference/import.rst:622

msgid ""

"Before Python loads cached bytecode from a ``.pyc`` file, it checks whether "

"the cache is up-to-date with the source ``.py`` file. By default, Python "

"does this by storing the source's last-modified timestamp and size in the "

"cache file when writing it. At runtime, the import system then validates the "

"cache file by checking the stored metadata in the cache file against the "

"source's metadata."

msgstr ""

#: ../../reference/import.rst:629

msgid ""

"Python also supports \"hash-based\" cache files, which store a hash of the "

"source file's contents rather than its metadata. There are two variants of "

"hash-based ``.pyc`` files: checked and unchecked. For checked hash-based ``."

"pyc`` files, Python validates the cache file by hashing the source file and "

"comparing the resulting hash with the hash in the cache file. If a checked "

"hash-based cache file is found to be invalid, Python regenerates it and "

"writes a new checked hash-based cache file. For unchecked hash-based ``."

"pyc`` files, Python simply assumes the cache file is valid if it exists. "

"Hash-based ``.pyc`` files validation behavior may be overridden with the :"

"option:`--check-hash-based-pycs` flag."

msgstr ""

#: ../../reference/import.rst:640

msgid ""

"Added hash-based ``.pyc`` files. Previously, Python only supported timestamp-"

"based invalidation of bytecode caches."

msgstr ""

#: ../../reference/import.rst:646

msgid "The Path Based Finder"

msgstr ""

#: ../../reference/import.rst:651

msgid ""

"As mentioned previously, Python comes with several default meta path "

"finders. One of these, called the :term:`path based finder` (:class:"

"`~importlib.machinery.PathFinder`), searches an :term:`import path`, which "

"contains a list of :term:`path entries <path entry>`. Each path entry names "

"a location to search for modules."

msgstr ""

#: ../../reference/import.rst:657

msgid ""

"The path based finder itself doesn't know how to import anything. Instead, "

"it traverses the individual path entries, associating each of them with a "

"path entry finder that knows how to handle that particular kind of path."

msgstr ""

#: ../../reference/import.rst:661

msgid ""

"The default set of path entry finders implement all the semantics for "

"finding modules on the file system, handling special file types such as "

"Python source code (``.py`` files), Python byte code (``.pyc`` files) and "

"shared libraries (e.g. ``.so`` files). When supported by the :mod:"

"`zipimport` module in the standard library, the default path entry finders "

"also handle loading all of these file types (other than shared libraries) "

"from zipfiles."

msgstr ""

#: ../../reference/import.rst:668

msgid ""

"Path entries need not be limited to file system locations. They can refer "

"to URLs, database queries, or any other location that can be specified as a "

"string."

msgstr ""

#: ../../reference/import.rst:672

msgid ""

"The path based finder provides additional hooks and protocols so that you "

"can extend and customize the types of searchable path entries. For example, "

"if you wanted to support path entries as network URLs, you could write a "

"hook that implements HTTP semantics to find modules on the web. This hook "

"(a callable) would return a :term:`path entry finder` supporting the "

"protocol described below, which was then used to get a loader for the module "

"from the web."

msgstr ""

#: ../../reference/import.rst:680

msgid ""

"A word of warning: this section and the previous both use the term *finder*, "

"distinguishing between them by using the terms :term:`meta path finder` and :"

"term:`path entry finder`. These two types of finders are very similar, "

"support similar protocols, and function in similar ways during the import "

"process, but it's important to keep in mind that they are subtly different. "

"In particular, meta path finders operate at the beginning of the import "

"process, as keyed off the :data:`sys.meta_path` traversal."

msgstr ""

#: ../../reference/import.rst:688

msgid ""

"By contrast, path entry finders are in a sense an implementation detail of "

"the path based finder, and in fact, if the path based finder were to be "

"removed from :data:`sys.meta_path`, none of the path entry finder semantics "

"would be invoked."

msgstr ""

#: ../../reference/import.rst:695

msgid "Path entry finders"

msgstr ""

#: ../../reference/import.rst:703

msgid ""

"The :term:`path based finder` is responsible for finding and loading Python "

"modules and packages whose location is specified with a string :term:`path "

"entry`. Most path entries name locations in the file system, but they need "

"not be limited to this."

msgstr ""

#: ../../reference/import.rst:708

msgid ""

"As a meta path finder, the :term:`path based finder` implements the :meth:"

"`~importlib.abc.MetaPathFinder.find_spec` protocol previously described, "

"however it exposes additional hooks that can be used to customize how "

"modules are found and loaded from the :term:`import path`."

msgstr ""

#: ../../reference/import.rst:713

msgid ""

"Three variables are used by the :term:`path based finder`, :data:`sys."

"path`, :data:`sys.path_hooks` and :data:`sys.path_importer_cache`. The "

"``__path__`` attributes on package objects are also used. These provide "

"additional ways that the import machinery can be customized."

msgstr ""

#: ../../reference/import.rst:718

msgid ""

":data:`sys.path` contains a list of strings providing search locations for "

"modules and packages. It is initialized from the :envvar:`PYTHONPATH` "

"environment variable and various other installation- and implementation-"

"specific defaults. Entries in :data:`sys.path` can name directories on the "

"file system, zip files, and potentially other \"locations\" (see the :mod:"

"`site` module) that should be searched for modules, such as URLs, or "

"database queries. Only strings should be present on :data:`sys.path`; all "

"other data types are ignored."

msgstr ""