ncoghlan at gmail
May 23, 2012, 6:02 AM
On Wed, May 23, 2012 at 10:31 PM, Eric V. Smith <eric [at] trueblade> wrote:
Re: PEP 420 - dynamic path computation is missing rationale
[In reply to]
> 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:
"""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
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
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.
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
Python-Dev mailing list
Python-Dev [at] python