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.)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4