[Python-checkins] r52292 - sandbox/trunk/import_in_py/importer.py

brett.cannon python-checkins at python.org
Thu Oct 12 01:56:57 CEST 2006


Author: brett.cannon
Date: Thu Oct 12 01:56:56 2006
New Revision: 52292

Modified:
   sandbox/trunk/import_in_py/importer.py
Log:
Update some ideas.


Modified: sandbox/trunk/import_in_py/importer.py
==============================================================================
--- sandbox/trunk/import_in_py/importer.py	(original)
+++ sandbox/trunk/import_in_py/importer.py	Thu Oct 12 01:56:56 2006
@@ -34,14 +34,18 @@
 Possible Py3K improvements:
     * Have __import__ check for sys.modules entry to alleviate need for every
       loader to do so.
-    * Have __import__ pass in module to initialize for imported module so to
-      alleviate loader from having to pull from sys.modules.
+    * Have __import__ pass into the loader the module to be initialized so as
+      remove that boilerplate (also keeps sys.modules manipulation within
+      __import__ when the previous suggestion is used).
     * Put importer objects directly into sys.path to remove need for
       sys.path_importer_cache.  Could leave string entries on sys.path that do
-      not have an importer that can handle them so they can be retried at the
-      next needed import (that was not found in sys.modules).
+      not have an importer so they can be re-checked the next time a new import
+      is attempted.
+        + If __import__ handles sys.modules then the impact from having to
+          recheck sys.path entries that lack an importer is minimized as it is
+          only on imports that have not been handled before.
       
-XXX PTL use-case:
+PTL use-case:
     * Tweaked source files that need to be pre-processed before they are imported.
     * Should be able to write out bytecode files easily.
     * Should let them use as much base infrastructure from the source and bytecode
@@ -58,7 +62,7 @@
             - Set 'handles' to bytecode extension
                 * 'ptlc'
                 
-XXX zipimport use-case:
+zipimport use-case:
     * New path_hooks function.
         + If sys.path entry is an existing zip file, return an importer for it.
         + Initialize the path_hooks function with handlers that are to be considered
@@ -72,7 +76,8 @@
             - Have a 'name' attribute.
     * PySourceHandler() and PyBytecodeHandler() would need to switch to accepting a
       file-like object that has a read() method along with a name attribute (for use
-      in compile() for error reporting).
+      in compile() for error reporting).  Also do not pass in a source provider for
+      the bytecode handler so as to suppress that writing of new bytecode.
 
 """
 from __future__ import with_statement
@@ -230,6 +235,12 @@
 class PySourceHandler(object):
 
     """Handler for importing Python source modules."""
+    
+    # XXX Need to have a way to generate bytecode when none was found in the
+    # first place.  If there ends up being too much overlap with the bytecode
+    # handler in terms of bytecode generation then consider
+    # following the current convention and have a unified source/bytecode
+    # handler that does it all.
 
     handles = 'py'
     


More information about the Python-checkins mailing list