At 01:19 PM 5/31/2010 -0700, Brett Cannon wrote:

But as long as whatever mechanism gets exposed allows people to work from a module name that will be enough. The path connection is not required as load_module is the end-all-be-all method. If we have a similar API added for .pth files that works off of module names then those loaders that don't want to work from file paths don't have to.

Right - that's why I suggested that a high-level request like get_pth_contents() would give the implementer the most flexibility. Then they don't have to fake a filesystem if they don't actually work that way. For example, a database that maps module names to code objects has no need for paths at all, and could just return either ['*'] or None depending on whether the package was marked as a namespace package in the database... without needing to fake up the existence of a .pth file in a virtual file system. (Of course, since lots of implementations *do* use filesystem-like backends, giving them some utility functions they can use to implement the API on top of filesystem operations gives us the best of both worlds.)