[Python-Dev] Import hooks falling back on built-in import machinery? (original) (raw)

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.

--Guido

On 5/25/06, Georg Brandl <g.brandl at gmx.net> wrote:

While working on a patch involving sys.pathimportercache, I discovered that if a pathhooks import hook has been found for a given sys.path entry, but isn't able to import a specific module, findmodule() 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.pathhooks 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.pathhooks 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