Add a sentence clarifying that once a path_hooks importer has
been found for a sys.path entry, the builtin import machinery will not handle that entry any longer.
This commit is contained in:
parent
0cae307351
commit
790d967970
17
pep-0302.txt
17
pep-0302.txt
|
@ -311,13 +311,16 @@ Specification part 2: Registering Hooks
|
|||
sequence to determine if they can handle a given path item. The
|
||||
callable is called with one argument, the path item. The callable
|
||||
must raise ImportError if it is unable to handle the path item, and
|
||||
return an importer object if it can handle the path item. The
|
||||
callable is typically the class of the import hook, and hence the
|
||||
class __init__ method is called. (This is also the reason why it
|
||||
should raise ImportError: an __init__ method can't return anything.
|
||||
This would be possible with a __new__ method in a new style class,
|
||||
but we don't want to require anything about how a hook is
|
||||
implemented.)
|
||||
return an importer object if it can handle the path item. Note
|
||||
that if the callable returns an importer object for a specific
|
||||
sys.path entry, the builtin import machinery will not be invoked
|
||||
to handle that entry any longer, even if the importer object later
|
||||
fails to find a specific module. The callable is typically the
|
||||
class of the import hook, and hence the class __init__ method is
|
||||
called. (This is also the reason why it should raise ImportError:
|
||||
an __init__ method can't return anything. This would be possible
|
||||
with a __new__ method in a new style class, but we don't want to
|
||||
require anything about how a hook is implemented.)
|
||||
|
||||
The results of path hook checks are cached in
|
||||
sys.path_importer_cache, which is a dictionary mapping path entries
|
||||
|
|
Loading…
Reference in New Issue