Fixed naive description of how relative imports work (spotted by Guido).

This commit is contained in:
Just van Rossum 2002-12-26 18:00:40 +00:00
parent 6d66240b0c
commit d208dc5175
1 changed files with 9 additions and 7 deletions

View File

@ -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