[Python-Dev] Import hooks falling back on built-in import machinery?

Guido van Rossum guido at python.org
Thu May 25 20:25:50 CEST 2006

Good catch. I think this would save a certain number of unnecessary
stat() calls.

But it does change semantics, so we can't fix this in 2.4. In 2.5, we
should warn hook authors that this might affect them.

The PEP ought to be updated to clarify this.


On 5/25/06, Georg Brandl <g.brandl at gmx.net> wrote:
> While working on a patch involving sys.path_importer_cache, I discovered
> that if a path_hooks import hook has been found for a given sys.path entry,
> but isn't able to import a specific module, find_module() tries to import
> the module from this sys.path entry as a regular file.
> This results in e.g. doing an open call to /usr/lib/python25.zip/x.py when
> I do "import x", while I think that once a sys.path entry has been identified
> as belonging to a sys.path_hooks importer instance, it shouldn't be handled
> by the built-in machinery anymore since the path string could be anything.
> PEP 302 says "...it was chosen to ... simply fall back to the built-in logic
> if no hook on sys.path_hooks could handle the path item", but that's
> refering to sys.path entries, not individual module names to be imported.
> Georg
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list