Fixed naive description of how relative imports work (spotted by Guido).
This commit is contained in:
parent
6d66240b0c
commit
d208dc5175
16
pep-0302.txt
16
pep-0302.txt
|
@ -192,15 +192,17 @@ Specification part 1: The Importer Protocol
|
|||
|
||||
The built-in __import__ function (known as PyImport_ImportModuleEx
|
||||
in import.c) will then check to see whether the module doing the
|
||||
import is a package by looking for a __path__ variable in the
|
||||
current global namespace. If it is indeed a package, it first tries
|
||||
to do the import relative to the package. For example if a package
|
||||
named "spam" does "import eggs", it will first look for a module
|
||||
named "spam.eggs". If that fails, the import continues as an
|
||||
import is a package or a submodule of a package. If it is indeed a
|
||||
(submodule of a) package, it first tries to do the import relative
|
||||
to the package (the parent package for a submodule). For example if
|
||||
a package named "spam" does "import eggs", it will first look for a
|
||||
module named "spam.eggs". If that fails, the import continues as an
|
||||
absolute import: it will look for a module named "eggs". Dotted
|
||||
name imports work pretty much the same: if package "spam" does
|
||||
"import eggs.bacon", first "spam.eggs.bacon" is tried, and only if
|
||||
that fails "eggs.bacon" is tried.
|
||||
"import eggs.bacon" (and "spam.eggs" exists), "spam.eggs.bacon" is
|
||||
tried and if that fails "eggs.bacon" is tried. (There are more
|
||||
subtleties that are not described here, but these are not relevant
|
||||
for implementers if the Importer Protocol.)
|
||||
|
||||
Deeper down in the mechanism, a dotted name import is split up by
|
||||
its components. For "import spam.ham", first an "import spam" is
|
||||
|
|
Loading…
Reference in New Issue