[Python-Dev] PEP 420 - dynamic path computation is missing rationale (original) (raw)

PJ Eby pje at telecommunity.com
Wed May 23 05:58:32 CEST 2012

On Tue, May 22, 2012 at 9:58 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

If you wanted to do this without changing the sys.metapath hook API, you'd have to pass an object to findmodule() that did the dynamic lookup of the value in obj.iter. Something like:

class LazyPath: def init(self, modname, attribute): self.modname = modname self.attribute = attribute def iter(self): return iter(getattr(sys.module[self.modname], self.attribute)) A potentially cleaner alternative to consider is tweaking the findloader API spec so that it gets used at the meta path level as well as at the path hooks level and is handed a callable that dynamically retrieves the path rather than a direct reference to the path itself. The full signature of findloader would then become: def findloader(fullname, getpath=None): # fullname as for findmodule # When getpath is None, it means the finder is being called as a path hook and # should use the specific path entry passed to init # In this case, namespace package portions are returned as (None, portions) # Otherwise, the finder is being called as a metapath hook and getpath() will return the relevant path # Any namespace packages are then returned as (loader, portions) There are two major consequences of this latter approach: - the PEP 302 findmodule API would now be a purely legacy interface for both the metapath and pathhooks, used only if findloader is not defined - it becomes trivial to tell whether a particular name references a package or not without needing to load it first: findloader() returns a non-empty iterable for the list of portions That second consequence is rather appealing: it means you'd be able to implement an almost complete walk of a package hierarchy without having to import anything (although you would miss old-style namespace packages and any other packages that alter their own path in init, so you may still want to load packages to make sure you found everything. You could definitively answer the "is this a package or not?" question without running any code, though). The first consequence is also appealing, since the findmodule() name is more than a little misleading. The "findmodule" name strongly suggests that the method is expected to return a module object, and that's just wrong - you actually find a loader, then you use that to load the module.

While I see no problem with cleaning up the interface, I'm kind of lost as to the point of making a get_path callable, vs. just using the iterable interface you sketched. Python has iterables, so why add a call to get the iterable, when iter() or a straight "for" loop will do effectively the same thing? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120522/f7464d72/attachment.html>

More information about the Python-Dev mailing list