import.po

# Copyright (C) 2001-2024, Python Software Foundation
# This file is distributed under the same license as the Python package.
#
# Translators:
msgid ""
msgstr ""
"Project-Id-Version: Python 3.12\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2024-09-03 11:11+0800\n"
"PO-Revision-Date: 2018-05-23 16:17+0000\n"
"Last-Translator: Adrian Liaw <adrianliaw2000@gmail.com>\n"
"Language-Team: Chinese - TAIWAN (https://github.com/python/python-docs-zh-"
"tw)\n"
"Language: zh_TW\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=1; plural=0;\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 ":mod:`importlib`"

#: ../../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 ""
"parent/\n"
"    __init__.py\n"
"    one/\n"
"        __init__.py\n"
"    two/\n"
"        __init__.py\n"
"    three/\n"
"        __init__.py"

#: ../../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:127
msgid "Namespace packages"
msgstr ""

#: ../../reference/import.rst:133
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:141
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:147
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:154
msgid "See also :pep:`420` for the namespace package specification."
msgstr ""

#: ../../reference/import.rst:158
msgid "Searching"
msgstr ""

#: ../../reference/import.rst:160
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:166
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:173
msgid "The module cache"
msgstr ""

#: ../../reference/import.rst:178
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:185
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:191
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:198
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:208
msgid "Finders and loaders"
msgstr ""

#: ../../reference/import.rst:215
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:223
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:230
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:233
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:237
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:241
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:247
msgid "Import hooks"
msgstr ""

#: ../../reference/import.rst:257
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:261
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:267
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:274
msgid "The meta path"
msgstr ""

#: ../../reference/import.rst:280
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:289
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:295
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:306
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:316
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:320
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:325
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:332
msgid ""
"Use of :meth:`!find_module` by the import system now raises :exc:"
"`ImportWarning`."
msgstr ""

#: ../../reference/import.rst:336
msgid ""
":meth:`!find_module` has been removed. Use :meth:`~importlib.abc."
"MetaPathFinder.find_spec` instead."
msgstr ""

#: ../../reference/import.rst:342
msgid "Loading"
msgstr ""

#: ../../reference/import.rst:344
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:348
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"
"if spec.origin is None and spec.submodule_search_locations is not None:\n"
"    # namespace package\n"
"    sys.modules[spec.name] = module\n"
"elif not hasattr(spec.loader, 'exec_module'):\n"
"    module = spec.loader.load_module(spec.name)\n"
"else:\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:377
msgid "Note the following details:"
msgstr ""

#: ../../reference/import.rst:379
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:382
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:388
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:394
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:399
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:403
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:406
msgid ""
"The import system has taken over the boilerplate responsibilities of "
"loaders.  These were previously performed by the :meth:`importlib.abc.Loader."
"load_module` method."
msgstr ""

#: ../../reference/import.rst:412
msgid "Loaders"
msgstr ""

#: ../../reference/import.rst:414
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:419
msgid "Loaders must satisfy the following requirements:"
msgstr ""

#: ../../reference/import.rst:421
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:425
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:429
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:433
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:440
msgid "The :meth:`~importlib.abc.Loader.create_module` method of loaders."
msgstr ""

#: ../../reference/import.rst:443
msgid ""
"The :meth:`~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:448
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:453
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:457
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:463
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:467
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:472
msgid ""
"A :exc:`DeprecationWarning` is raised when ``exec_module()`` is defined but "
"``create_module()`` is not."
msgstr ""

#: ../../reference/import.rst:476
msgid ""
"An :exc:`ImportError` is raised when ``exec_module()`` is defined but "
"``create_module()`` is not."
msgstr ""

#: ../../reference/import.rst:480
msgid "Use of ``load_module()`` will raise :exc:`ImportWarning`."
msgstr ""

#: ../../reference/import.rst:484
msgid "Submodules"
msgstr "子模組"

#: ../../reference/import.rst:486
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:493
msgid ""
"spam/\n"
"    __init__.py\n"
"    foo.py"
msgstr ""
"spam/\n"
"    __init__.py\n"
"    foo.py"

#: ../../reference/import.rst:497
msgid "and ``spam/__init__.py`` has the following line in it::"
msgstr ""

#: ../../reference/import.rst:499
msgid "from .foo import Foo"
msgstr "from .foo import Foo"

#: ../../reference/import.rst:501
msgid ""
"then executing the following puts name bindings for ``foo`` and ``Foo`` in "
"the ``spam`` module::"
msgstr ""

#: ../../reference/import.rst:504
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 ""
">>> import spam\n"
">>> spam.foo\n"
"<module 'spam.foo' from '/tmp/imports/spam/foo.py'>\n"
">>> spam.Foo\n"
"<class 'spam.foo.Foo'>"

#: ../../reference/import.rst:510
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:517
msgid "Module spec"
msgstr ""

#: ../../reference/import.rst:519
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:524
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:530
msgid ""
"The module's spec is exposed as the ``__spec__`` attribute on a module "
"object. See :class:`~importlib.machinery.ModuleSpec` for details on the "
"contents of the module spec."
msgstr ""

#: ../../reference/import.rst:539
msgid "Import-related module attributes"
msgstr ""

#: ../../reference/import.rst:541
msgid ""
"The import machinery fills in these attributes on each module object during "
"loading, based on the module's spec, before the loader executes the module."
msgstr ""

#: ../../reference/import.rst:545
msgid ""
"It is **strongly** recommended that you rely on :attr:`__spec__` and its "
"attributes instead of any of the other individual attributes listed below."
msgstr ""

#: ../../reference/import.rst:551
msgid ""
"The ``__name__`` attribute must be set to the fully qualified name of the "
"module.  This name is used to uniquely identify the module in the import "
"system."
msgstr ""

#: ../../reference/import.rst:557
msgid ""
"The ``__loader__`` attribute must be set to the loader object that the "
"import machinery used when loading the module.  This is mostly for "
"introspection, but can be used for additional loader-specific functionality, "
"for example getting data associated with a loader."
msgstr ""

#: ../../reference/import.rst:562 ../../reference/import.rst:583
msgid ""
"It is **strongly** recommended that you rely on :attr:`__spec__` instead of "
"this attribute."
msgstr ""

#: ../../reference/import.rst:565
msgid ""
"The value of ``__loader__`` is expected to be the same as ``__spec__."
"loader``.  The use of ``__loader__`` is deprecated and slated for removal in "
"Python 3.14."
msgstr ""

#: ../../reference/import.rst:572
msgid ""
"The module's ``__package__`` attribute may be set.  Its value must be a "
"string, but it can be the same value as its ``__name__``.  When the module "
"is a package, its ``__package__`` value should be set to its ``__name__``.  "
"When the module is not a package, ``__package__`` should be set to the empty "
"string for top-level modules, or for submodules, to the parent package's "
"name.  See :pep:`366` for further details."
msgstr ""

#: ../../reference/import.rst:580
msgid ""
"This attribute is used instead of ``__name__`` to calculate explicit "
"relative imports for main modules, as defined in :pep:`366`."
msgstr ""

#: ../../reference/import.rst:586
msgid ""
"The value of ``__package__`` is expected to be the same as ``__spec__."
"parent``."
msgstr ""

#: ../../reference/import.rst:590
msgid ""
":exc:`ImportWarning` is raised if import falls back to ``__package__`` "
"instead of :attr:`~importlib.machinery.ModuleSpec.parent`."
msgstr ""

#: ../../reference/import.rst:595
msgid ""
"Raise :exc:`DeprecationWarning` instead of :exc:`ImportWarning` when falling "
"back to ``__package__``."
msgstr ""

#: ../../reference/import.rst:602
msgid ""
"The ``__spec__`` attribute must be set to the module spec that was used when "
"importing the module. Setting ``__spec__`` appropriately applies equally to :"
"ref:`modules initialized during interpreter startup <programs>`.  The one "
"exception is ``__main__``, where ``__spec__`` is :ref:`set to None in some "
"cases <main_spec>`."
msgstr ""

#: ../../reference/import.rst:608
msgid ""
"When ``__spec__.parent`` is not set, ``__package__`` is used as a fallback."
msgstr ""

#: ../../reference/import.rst:613
msgid ""
"``__spec__.parent`` is used as a fallback when ``__package__`` is not "
"defined."
msgstr ""

#: ../../reference/import.rst:619
msgid ""
"If the module is a package (either regular or namespace), the module "
"object's ``__path__`` attribute must be set.  The value must be iterable, "
"but may be empty if ``__path__`` has no further significance. If "
"``__path__`` is not empty, it must produce strings when iterated over. More "
"details on the semantics of ``__path__`` are given :ref:`below <package-path-"
"rules>`."
msgstr ""

#: ../../reference/import.rst:626
msgid "Non-package modules should not have a ``__path__`` attribute."
msgstr ""

#: ../../reference/import.rst:631
msgid ""
"``__file__`` is optional (if set, value must be a string). It indicates the "
"pathname of the file from which the module was loaded (if loaded from a "
"file), or the pathname of the shared library file for extension modules "
"loaded dynamically from a shared library. It might be missing for certain "
"types of modules, such as C modules that are statically linked into the "
"interpreter, and the import system may opt to leave it unset if it has no "
"semantic meaning (e.g. a module loaded from a database)."
msgstr ""

#: ../../reference/import.rst:640
msgid ""
"If ``__file__`` is set then the ``__cached__`` attribute might also be set,  "
"which is the path to any compiled version of the code (e.g. byte-compiled "
"file). The file does not need to exist to set this attribute; the path can "
"simply point to where the compiled file would exist (see :pep:`3147`)."
msgstr ""

#: ../../reference/import.rst:646
msgid ""
"Note that ``__cached__`` may be set even if ``__file__`` is not set.  "
"However, that scenario is quite atypical.  Ultimately, the loader is what "
"makes use of the module spec provided by the finder (from which ``__file__`` "
"and ``__cached__`` are derived).  So if a loader can load from a cached "
"module but otherwise does not load from a file, that atypical scenario may "
"be appropriate."
msgstr ""

#: ../../reference/import.rst:653
msgid ""
"It is **strongly** recommended that you rely on :attr:`__spec__` instead of "
"``__cached__``."
msgstr ""

#: ../../reference/import.rst:659
msgid "module.__path__"
msgstr "module.__path__"

#: ../../reference/import.rst:661
msgid ""
"By definition, if a module has a ``__path__`` attribute, it is a package."
msgstr ""

#: ../../reference/import.rst:663
msgid ""
"A package's ``__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, ``__path__`` is typically much more constrained "
"than :data:`sys.path`."
msgstr ""

#: ../../reference/import.rst:669
msgid ""
"``__path__`` must be an iterable of strings, but it may be empty. The same "
"rules used for :data:`sys.path` also apply to a package's ``__path__``, and :"
"data:`sys.path_hooks` (described below) are consulted when traversing a "
"package's ``__path__``."
msgstr ""

#: ../../reference/import.rst:674
msgid ""
"A package's ``__init__.py`` file may set or alter the package's ``__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 "
"``__path__`` manipulation code; the import machinery automatically sets "
"``__path__`` correctly for the namespace package."
msgstr ""

#: ../../reference/import.rst:682
msgid "Module reprs"
msgstr ""

#: ../../reference/import.rst:684
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:688
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:695
msgid "Here are the exact rules used:"
msgstr ""

#: ../../reference/import.rst:697
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:701
msgid ""
"If the module has a ``__file__`` attribute, this is used as part of the "
"module's repr."
msgstr ""

#: ../../reference/import.rst:704
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:707
msgid "Otherwise, just use the module's ``__name__`` in the repr."
msgstr ""

#: ../../reference/import.rst:709
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:717
msgid "Cached bytecode invalidation"
msgstr ""

#: ../../reference/import.rst:719
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 "