Specify import hook support.
This commit is contained in:
parent
cb5f8f7831
commit
b200983097
54
pep-0382.txt
54
pep-0382.txt
|
@ -114,6 +114,12 @@ also want to extend __path__). At most one such asterisk gets
|
|||
prepended to the path. In addition, the (possibly dotted) names of all
|
||||
namespace packages are added to the set sys.namespace_packages.
|
||||
|
||||
If the first directory found on the path only contains an __init__.py
|
||||
and no \*.pth file, searching the path stops; IOW, namespace packages
|
||||
must include at least one .pth file. If both \*.pth files and an
|
||||
__init__.py had been found, search continues looking for further
|
||||
.pth files.
|
||||
|
||||
No other change to the importing mechanism is made; searching modules
|
||||
(including __init__.py) will continue to stop at the first module
|
||||
encountered. In summary, the process import a package foo works like
|
||||
|
@ -121,13 +127,48 @@ this:
|
|||
|
||||
1. sys.path is search for a directory foo, or a file foo.<ext>.
|
||||
If a file is found and no directory, it is treated as a module, and imported.
|
||||
2. if it is a directory, it checks for \*.pth files. If it finds
|
||||
any, a package is created, and its __path__ is extended.
|
||||
3. The __init__ module is imported; this import will search the
|
||||
__path__ that got computed already.
|
||||
4. If neither a \*.pth file nor an __init__.py was found, the
|
||||
2. if it is a directory, it checks for both \*.pth and an __init__ file. If it finds
|
||||
only \*.pth files, a package is created, and its __path__ is extended.
|
||||
3. If neither a \*.pth file nor an __init__.py was found, the
|
||||
directory is skipped, and search for the module/package
|
||||
continues.
|
||||
continues. If an __init__.py was found, further search only looks
|
||||
for \*.pth files.
|
||||
4. If an __init__ module was found, it is imported, with __path__
|
||||
being initialized to the path computed from the \*.pth files.
|
||||
|
||||
Impact on Import Hooks
|
||||
----------------------
|
||||
|
||||
Both loaders and finders as defined in PEP 302 will need to be changed
|
||||
to support namespace packages. Failure to comform to the protocol
|
||||
below might cause a package not being recognized as a namespace
|
||||
package; loaders and finders not supporting this protocol must raise
|
||||
AttributeError when the functions below get accessed.
|
||||
|
||||
Finders need to support looking for \*.pth files in step 1 of above
|
||||
algorithm. To do so, a finder must support a method:
|
||||
|
||||
finder.find_path(fullname, path=None)
|
||||
|
||||
This method will be called in the same manner as find_module, and it
|
||||
must return a list of strings, each representing the contents of one
|
||||
\*.pth file. If fullname is not found, is not a package, or does not
|
||||
have any \*.pth files, None must be returned.
|
||||
|
||||
If any \*.pth files are found, but no loader was returned from
|
||||
find_module, a package is created and initialized with the path.
|
||||
|
||||
If a loader was return, but no \*.pth files, load_module is called
|
||||
as defined in PEP 302.
|
||||
|
||||
If both \*.pth files where found, and a loader was returned, a new
|
||||
method is called on the loader:
|
||||
|
||||
loader.load_module_with_path(load_module, path)
|
||||
|
||||
where the path parameter is the list of strings containing the
|
||||
contents of all \*.pth files.
|
||||
|
||||
|
||||
Discussion
|
||||
==========
|
||||
|
@ -159,6 +200,7 @@ having users and tools starting to special-case 2.7). Prospective
|
|||
users of this feature are encouraged to comment on this particular
|
||||
question.
|
||||
|
||||
|
||||
Copyright
|
||||
=========
|
||||
|
||||
|
|
Loading…
Reference in New Issue