[Import-SIG] PEP 420 issue: extend_path
brett at python.org
Fri May 11 05:13:43 CEST 2012
On Thu, May 10, 2012 at 9:56 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, May 11, 2012 at 11:02 AM, Eric V. Smith <eric at trueblade.com>
> > Feel free to wordsmith it.
> Only minor quibbles:
> "load a regular package" -> "load a module or self-contained package"
> (when we get a loader, we don't know if it's for a module or a
> package, and I also prefer "self-contained package" over "regular
> package", since it's more future proof terminology)
> "will be a list containing only" -> "will contain only"
> Independent of PEP 420, something we should probably consider for the
> official documentation of the import system is making a clearer
> distinction between importers (on sys.meta_path) and finders (returned
> by sys.path_hooks entries) than was the case in PEP 302 (which calls
> them all finders).
> - installed directly on sys.meta_path
> - called via importer.find_module(fullname, path) (where path=None for
> a sys.path based import)
> - created by the path importer for individual path entries by
> traversing sys.path_hooks
> - stored in sys.path_importer_cache
> - called via finder.find_loader(fullname) (if defined), otherwise via
> - returned from finder.find_loader() (or finder.find_module())
> - called via loader.load_module(fullname)
> importlib is *mostly* consistent with the above scheme (with
> FrozenImporter, BuiltinImporter, FileFinder and the various *Loader
> classes), but PathFinder doesn't fit (it's a meta_path importer, but
> uses a "*Finder" name). We could always just change the name to
> PathImporter, keeping PathFinder around as a backwards compatibility
But PathFinder is not an importer as it is not a finder *and* a loader:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Import-SIG