Xavier de Gaye added the comment:
I was bitten by this behavior while, new to the importlib library, I
was trying to understand if one has to call recursively find_loader
for a dotted module name (in the way it must be done when using
imp.find_module), since the documentation on find_loader is
Roundup Robot added the comment:
New changeset 358be7742377 by Brett Cannon in branch '3.3':
Issue #16489: Make it clearer that importlib.find_loader() requires
http://hg.python.org/cpython/rev/358be7742377
New changeset ba1d7447bd1b by Brett Cannon in branch 'default':
Merge fix for #16489
Brett Cannon added the comment:
I clarified the wording in 3.3 and default. I also opened issue #16492 to add a
keyword-only argument to find_loader() to have it import parent packages for
you if you so desire.
--
resolution: invalid - fixed
stage: - committed/rejected
Xavier de Gaye added the comment:
Thanks, this is great!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16489
___
___
Python-bugs-list mailing
New submission from Xavier de Gaye:
Create the following tree:
foo.py
mypackage
__init__.py
and get a loader for the non existent module 'mypackage.foo'.
$ mkdir tmp
$ cd tmp
$ foo.py
$ mkdir mypackage
$ mypackage/__init__.py
$ ./python
Python 3.4.0a0 (default:53a7c2226a2b,
Xavier de Gaye added the comment:
And yes, find_loader returns None, when correctly invoked with the
path argument:
importlib.find_loader('mypackage.foo', ['./mypackage/'])
--
___
Python tracker rep...@bugs.python.org
R. David Murray added the comment:
Not necessarily. The fact that there is nothing to load doesn't mean it isn't
the right loader if there *was* something to load. But I'll leave it to the
import experts to say what the expected behavior is. I'll admit that I can't
figure it out from a
Brett Cannon added the comment:
Everything is working as expected; you left out the path argument::
importlib.find_loader('package.foo', ['package'])
This works the way it does because otherwise we would have to stat every single
time from the top level on down and that is extremely costly.
Xavier de Gaye added the comment:
Maybe find_loader could check its parameters, notice that the name is a
dotted name, that path is None and in this case, not return a loader ?
--
___
Python tracker rep...@bugs.python.org
Brett Cannon added the comment:
That won't work as frozen and builtin modules don't care about the path.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16489
___
Xavier de Gaye added the comment:
Not necessarily. The fact that there is nothing to load doesn't
mean it isn't the right loader if there *was* something to load.
But it is not even the right loader if there *was* something to load,
as get_filename() returns './foo.py' which is wrong even if
Xavier de Gaye added the comment:
If one would want to fix this, one way to do it could be to change the
following two methods of the PathFinder class such that:
find_module() does not set path to sys.path when its path argument
is None, so as to keep this information for _get_loader()
Brett Cannon added the comment:
Feel free to submit a patch, but I'm personally not motivated enough to try to
change this on my own.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16489
Eric V. Smith added the comment:
It might be more motivating if you (Xavier de Gaye) could let us know of a
real-world problem caused by this behavior.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16489
14 matches
Mail list logo
