- removed the importer-on-sys.path feature (an update patch will be posted

later)
- renamed imp.find_module2() to imp.get_loader() as suggested by Guido.

pep-0302.txt

@@ -169,13 +169,6 @@ Rationale
     import would go through sys.meta_path, making it the central import
     dispatcher.)
 
-    As a bonus, the idea from the second paragraph of this section was
-    implemented after all: a sys.path item may *be* an importer object.
-    This use is discouraged for general purpose code, but it's very
-    convenient, for experimentation as well as for projects of which
-    it's known that no component wrongly assumes that sys.path items are
-    strings.
-
 
 Specification part 1: The Importer Protocol
 
@@ -301,14 +294,8 @@ Specification part 2: Registering Hooks
 
     Path hooks are called as part of sys.path (or package.__path__)
     processing, at the point where their associated path item is
-    encountered.  A path hook can be registered in either of two ways:
+    encountered.  A path hook is registered by adding an importer
-
+    factory to sys.path_hooks.
-    - By simply including an importer object directly on the path.
-      This approach is discouraged for general purpose hooks, as
-      existing code may not be expecting non-strings to exist on
-      sys.path.
-
-    - By registering an importer factory in sys.path_hooks.
 
     sys.path_hooks is a list of callables, which will be checked in
     sequence to determine if they can handle a given path item.  The
@@ -345,13 +332,10 @@ Packages and the role of __path__
     treat it as a package.  The __path__ variable is used instead of
     sys.path when importing submodules of the package.  The rules for
     sys.path therefore also apply to pkg.__path__.  So sys.path_hooks is
-    also consulted when pkg.__path__ is traversed and importer objects
+    also consulted when pkg.__path__ is traversed.  Meta importers don't
-    as path items are also allowed (yet, are discouraged for the same
+    necessarily use sys.path at all to do their work and may therefore
-    reasons as they are discouraged on sys.path, at least for general
+    ignore the value of pkg.__path__.  In this case it is still advised
-    purpose code).  Meta importers don't necessarily use sys.path at all
+    to set it to list, which can be empty.
-    to do their work and may therefore ignore the value of pkg.__path__.
-    In this case it is still advised to set it to list, which can be
-    empty.
 
 
 Optional Extensions to the Importer Protocol
@@ -430,10 +414,10 @@ Integration with the 'imp' module
     "they expose the built-in import mechanism" to "they expose the
     basic *unhooked* built-in import mechanism".  They simply won't
     invoke any import hooks.  A new imp module function is proposed (but
-    not yet implemented) under the name "find_module2", which is used as
+    not yet implemented) under the name "get_loader", which is used as
     in the following pattern:
 
-        loader = imp.find_module2(fullname, path)
+        loader = imp.get_loader(fullname, path)
         if loader is not None:
             loader.load_module(fullname)
 
@@ -450,8 +434,8 @@ Integration with the 'imp' module
 Forward Compatibility
 
     Existing __import__ hooks will not invoke new-style hooks by magic,
-    unless they call the original __import__ function as a fallback. For
+    unless they call the original __import__ function as a fallback.
-    example, ihooks.py, iu.py and imputil.py are in this sense not
+    For example, ihooks.py, iu.py and imputil.py are in this sense not
     forward compatible with this PEP.
 
 
@@ -560,7 +544,7 @@ References and Footnotes
     [7] The path argument to importer.find_module() is there because the
     pkg.__path__ variable may be needed at this point.  It may either
     come from the actual parent module or be supplied by
-    imp.find_module() or the proposed imp.find_module2() function.
+    imp.find_module() or the proposed imp.get_loader() function.
 
     [8] Quixote, a framework for developing Web applications
     http://www.mems-exchange.org/software/quixote/