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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
