[Python-checkins] r70726 - peps/trunk/pep-0302.txt

[brett.cannon]

Author: brett.cannon
Date: Mon Mar 30 18:49:41 2009
New Revision: 70726

Log:
Move over to using the term 'finder' as used in importlib.

Modified:
   peps/trunk/pep-0302.txt

Modified: peps/trunk/pep-0302.txt
==============================================================================
--- peps/trunk/pep-0302.txt	(original)
+++ peps/trunk/pep-0302.txt	Mon Mar 30 18:49:41 2009
@@ -206,13 +206,13 @@
     imports.  By the time an importer gets a request for "spam.ham",
     module "spam" has already been imported.
 
-    The protocol involves two objects: an importer and a loader.  An
-    importer object has a single method:
+    The protocol involves two objects: a finder and a loader.  A
+    finder object has a single method:
 
-        importer.find_module(fullname, path=None)
+        finder.find_module(fullname, path=None)
 
     This method will be called with the fully qualified name of the
-    module.  If the importer is installed on sys.meta_path, it will
+    module.  If the finder is installed on sys.meta_path, it will
     receive a second argument, which is None for a top-level module, or
     package.__path__ for submodules or subpackages[7].  It should return
     a loader object if the module was found, or None if it wasn't.  If
@@ -228,17 +228,17 @@
     propagated.  If load_module() is asked to load a module that it
     cannot, ImportError is to be raised.
 
-    In many cases the importer and loader can be one and the same
-    object: importer.find_module() would just return self.
+    In many cases the finder and loader can be one and the same
+    object: finder.find_module() would just return self.
 
     The 'fullname' argument of both methods is the fully qualified
     module name, for example "spam.eggs.ham".  As explained above, when
-    importer.find_module("spam.eggs.ham") is called, "spam.eggs" has
+    finder.find_module("spam.eggs.ham") is called, "spam.eggs" has
     already been imported and added to sys.modules.  However, the
     find_module() method isn't necessarily always called during an
     actual import: meta tools that analyze import dependencies (such as
     freeze, Installer or py2exe) don't actually load modules, so an
-    importer shouldn't *depend* on the parent package being available in
+    finder shouldn't *depend* on the parent package being available in
     sys.modules.
 
     The load_module() method has a few responsibilities that it must
@@ -301,7 +301,7 @@
     Meta hooks are called at the start of import processing, before any
     other import processing (so that meta hooks can override sys.path
     processing, or frozen modules, or even built-in modules).  To
-    register a meta hook, simply add the importer object to
+    register a meta hook, simply add the finder object to
     sys.meta_path (the list of registered meta hooks).
 
     Path hooks are called as part of sys.path (or package.__path__)
@@ -498,7 +498,7 @@
     optional) it is not clear that the __loader__ attribute will be
     helpful, in practice.
 
-    On the other hand, importer objects are mostly permanent, as they
+    On the other hand, finder objects are mostly permanent, as they
     live or are kept alive on sys.meta_path, sys.path_importer_cache, so
     for a loader to keep a reference to the importer costs us nothing
     extra.  Whether loaders will ever need to carry so much independent
@@ -575,7 +575,7 @@
     [6] imp.set_frozenmodules() patch
     http://www.python.org/sf/642578
 
-    [7] The path argument to importer.find_module() is there because the
+    [7] The path argument to finder.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.get_loader() function.