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 <[EMAIL PROTECTED]> 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@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/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to