On May 23, 2012 9:02 AM, "Nick Coghlan" email@example.com wrote:
On Wed, May 23, 2012 at 10:31 PM, Eric V. Smith firstname.lastname@example.org
On 05/22/2012 09:49 PM, PJ Eby wrote:
It shouldn't - all you should need is to use getattr(sys.modules[self.modname], self.attr) instead of referencing a parent path object directly.
The problem isn't the lookup, it's coming up with self.modname and self.attr. As it currently stands, PathFinder.find_module is given the parent path, not the module name and attribute name used to look up the parent path using sys.modules and getattr.
Right, that's what PJE and I were discussing. Instead of passing in the path object directly, you can instead pass an object that *lazily* retrieves the path object in its __iter__ method:
class LazyIterable: """On iteration, retrieves a reference to a named iterable and returns an iterator over that iterable""" def __init__(self, modname, attribute): self.modname = modname self.attribute = attribute def __iter__(self): mod = import_module(self.modname) # Will almost always get a hit directly in sys.modules return iter(getattr(mod, self.attribute)
Where importlib currently passes None or sys.path as the path argument to find_module(), instead pass "LazyIterable('sys', 'path')" and where it currently passes package.__path__, instead pass "LazyIterable(package.__name__, '__path__')".
The existing for loop iteration and tuple() calls should then take care of the lazy lookup automatically.
That way, the only code that needs to know the values of modname and attribute is the code that already has access to those values.
Perhaps calling it a ModulePath instead of a LazyIterable would be better?
Also, this is technically a change from PEP 302, which says the actual sys.path or __path__ are passed to find_module(). I'm not sure whether any find_module() code ever written actually *cares* about this, though. (Especially if, as I believe I understand in this context, we're only talking about meta-importers.)