[Python-3000] Changing the import machinery

[Nick Coghlan]

Ian Bicking wrote:
> Maybe you wouldn't have to mix it all together... if sys.path, 
> sys.meta_path, and sys.modules (and maybe some other stuff I don't know 
> of) were really instance variables of some ModuleEnvironment object, and 
> you could instantiate a new ModuleEnvironment that was specific to 
> templates.  Probably to be filed under crazy ideas.

Not really all that crazy. . . .

Think about it - the import mechanism is a bunch of related functions for 
finding and loading modules. Currently, those are all stored as module level 
functions, which forces their shared state to be global for the entire 
interpeter. What's the conventional solution for dealing with a set of 
functions which need to share complex state?

Now, suppose that there was, in sys, the moral equivalent of:

   sys.importer = imp.Importer()

sys.path, sys.meta_path, sys.path_hooks, sys.path_importer_cache and 
sys.modules would then all be attributes of the Importer object.

If sys was changed to be a class rather than a module, then the top-level 
attributes could be retained as properties accessing sys.importer.

Applications wanting to tightly control sys.path would simply replace 
sys.importer with a different importer object.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org