- some whitespace normalization (two spaces after sentence endings; yuck! ;-)

- minor edits
- added short Forward Compatibility section
- added comment about the Quixote/PTL use case to Open Issues

pep-0302.txt

@@ -271,8 +271,8 @@ Specification part 1: The Importer Protocol
       with an importer.
 
     If the module is a Python module (as opposed to a built-in module or
-    an dynamically loaded extension), it should execute the module's
-    code in the module's global name space (module.__dict__).
+    a dynamically loaded extension), it should execute the module's code
+    in the module's global name space (module.__dict__).
 
     Here is a minimal pattern for a load_module() method:
 
@@ -347,9 +347,9 @@ Packages and the role of __path__
     as path items are also allowed (yet, are discouraged for the same
     reasons as they are discouraged on sys.path, at least for general
     purpose code).  Meta importers don't necessarily use sys.path at all
-    to do their work and therefore may also ignore the value of
-    pkg.__path__.  In this case it is still advised 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
@@ -371,10 +371,10 @@ Optional Extensions to the Importer Protocol
     This method returns the data as a string, or raise IOError if the
     "file" wasn't found.  The 'name' argument should be seen as a
     'cookie', meaning the protocol doesn't prescribe any semantics for
-    it. However, for importer objects that have some file system-like
+    it.  However, for importer objects that have some file system-like
     properties (for example zipimporter) it is recommended to use os.sep
     as a separator character to specify a (possibly virtual) directory
-    hierarchy. For example if the importer allows access to a module's
+    hierarchy.  For example if the importer allows access to a module's
     source code via i.get_data(name), the 'name' argument should be
     constructed like this:
 
@@ -427,9 +427,9 @@ Integration with the 'imp' module
     existing imp.find_module() and imp.load_module() calls changes from:
     "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
-    under the name "find_module2", with is used like the following
-    pattern:
+    invoke any import hooks.  A new imp module function is proposed (but
+    not yet implemented) under the name "find_module2", which is used as
+    in the following pattern:
 
         loader = imp.find_module2(fullname, path)
         if loader is not None:
@@ -445,6 +445,14 @@ Integration with the 'imp' module
     ImpWrapper class) included with the patch.
 
 
+Forward Compatibility
+
+    Existing __import__ hooks will not invoke new-style hooks by magic,
+    unless they call the original __import__ function as a fallback. For
+    example, ihooks.py, iu.py and imputil.py are in this sense not
+    forward compatible with this PEP.
+
+
 Open Issues
 
     The new hook method allows for the possibility of objects other than
@@ -504,12 +512,22 @@ Open Issues
 
     It was suggested on python-dev that it would be useful to be able to
     receive a list of available modules from an importer and/or a list
-    of available data files for use with the get_data() method. The
+    of available data files for use with the get_data() method.  The
     protocol could grow two additional extensions, say list_modules()
     and list_files().  The latter makes sense on loader objects with a
     get_data() method.  However, it's a bit unclear which object should
     implement list_modules(): the importer or the loader or both?
 
+    This PEP is biased towards loading modules from alternative places:
+    it currently doesn't offer dedicated solutions for loading modules
+    from alternative file formats or with alternative compilers.  In
+    contrast, the ihooks module from the standard library does have a
+    fairly straightforward way to do this.  The Quixote project [8] uses
+    this technique to import PTL files as if they are ordinary Python
+    modules.  To do the same with the new hooks would either mean to add
+    a new module implementing a subset of ihooks as a new-style
+    importer, or add a hookable built-in path importer object.
+
 
 Implementation
 
@@ -542,6 +560,9 @@ References and Footnotes
     come from the actual parent module or be supplied by
     imp.find_module() or the proposed imp.find_module2() function.
 
+    [8] Quixote, a framework for developing Web applications
+    http://www.mems-exchange.org/software/quixote/
+
 
 Copyright