From 790d967970d6249cb96ffe28069e65210812ad4a Mon Sep 17 00:00:00 2001 From: Georg Brandl Date: Fri, 11 Aug 2006 07:11:14 +0000 Subject: [PATCH] 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. --- pep-0302.txt | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/pep-0302.txt b/pep-0302.txt index e26a0160a..8910a1756 100644 --- a/pep-0302.txt +++ b/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