[Python-Dev] Another approach for the import mechanism
Steve Holden
sholden@holdenweb.com
Thu, 5 Dec 2002 16:35:52 -0500
> I propose a different approach to the importer hook mechanism:
>
> - An importer register itself with sys.register_importer(), as suggested
> by MAL.
>
> - No .zip/.tar/.whatever files are ever included in sys.path
>
> - Alternative importers are only considered when the default importer
> mechanism fails (each entry in the path at a time, so that
> precedence is preserved).
>
Far too restrictive. You seem to be saying (unless I misunderstand) that an
alternative import can't override an element on the traditional sys.path. Is
there to be no way to replace existing system components by providing
replacements in zip files, in the same way that I could currently replace
httplib by putting my own httplib in a directory which I then place at the
beginning of sys.path?
> - Alternative importers, when activated, would be given the module name
> being imported, and would look for entries in the "current" iterated
> path by themselves.
>
Huh? Why restrict alternative importers to using a path? What if my importer
wants to provide randomly generated byte codes as part of a genetic
programming experiment?
> - A zip importer would, for example, look if the current iterated path
> have a file named "__init__.zip".
>
...and I'm not really sure what you mean by "iterated path".
> - The same importer could also be able to look for a file named
> "mypackage.zip", if "import mypackage.foo" is tried.
>
> What's your opinion about that?
>
I think I must be misunderstanding at a fairly basic level. This would seem
pretty inflexible to me.
regards
-----------------------------------------------------------------------
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
Previous .sig file retired to www.homeforoldsigs.com
-----------------------------------------------------------------------
> http://mail.python.org/mailman/listinfo/python-dev
>
>