[Python-checkins] python/nondist/peps pep-0302.txt,1.12,1.13

[jvr@users.sourceforge.net]

Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv22921

Modified Files:
	pep-0302.txt 
Log Message:
- added two items from Paul Moore to "Open Issues"
- removed section that still mentioned importers-on-sys.path


Index: pep-0302.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0302.txt,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** pep-0302.txt	1 Jan 2003 20:22:03 -0000	1.12
--- pep-0302.txt	2 Jan 2003 18:47:04 -0000	1.13
***************
*** 430,443 ****
  Open Issues
  
-     The new hook method allows for the possibility of objects other than
-     strings appearing on sys.path.  Existing code is entitled to assume
-     that sys.path only contains strings (the Python documentation states
-     this).  It is not clear if this will cause significant breakage.  In
-     particular, it is much less clear that code is entitled to assume
-     that sys.path contains a list of *directory names* - most code which
-     assumes that sys.path items contain strings also rely on this extra
-     assumption, and so could be considered as broken (or at least "not
-     robust") already.
- 
      Modules often need supporting data files to do their job,
      particularly in the case of complex packages or full applications.
--- 430,433 ----
***************
*** 480,487 ****
  
      On the other hand, importer objects are mostly permanent, as they
!     live or are kept alive on sys.meta_path, sys.path_importer_cache or
!     sys.path, 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 state for this to become a real issue is questionable.
  
      It was suggested on python-dev that it would be useful to be able to
--- 470,477 ----
  
      On the other hand, importer 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
!     state for this to become a real issue is questionable.
  
      It was suggested on python-dev that it would be useful to be able to
***************
*** 502,505 ****
--- 492,516 ----
      a new module implementing a subset of ihooks as a new-style
      importer, or add a hookable built-in path importer object.
+ 
+     There is no specific support within this PEP for "stacking" hooks. 
+     For example, it is not obvious how to write a hook to load modules
+     from ..tar.gz files by combining separate hooks to load modules from
+     .tar and ..gz files.  However, there is no support for such stacking
+     in the existing hook mechanisms (either the basic "replace
+     __import__" method, or any of the existing import hook modules) and
+     so this functionality is not an obvious requirement of the new
+     mechanism.  It may be worth considering as a future enhancement,
+     however.
+ 
+     It is possible (via sys.meta_path) to add hooks which run before
+     sys.path is processed.  However, there is no equivalent way of
+     adding hooks to run after sys.path is processed.  For now, if a hook
+     is required after sys.path has been processed, it can be simulated
+     by adding an arbitrary "cookie" string at the end of sys.path, and
+     having the required hook associated with this cookie, via the normal
+     sys.path_hooks processing.  In the longer term, the path handling
+     code will become a "real" hook on sys.meta_path, and at that stage
+     it will be possible to insert user-defined hooks either before or
+     after it.