Re: PEP 420 issue: extend_path

On Thu, May 10, 2012 at 9:56 PM, Nick Coghlan <[email protected]> wrote:

> On Fri, May 11, 2012 at 11:02 AM, Eric V. Smith <[email protected]>
> wrote:
> > 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).
>
> Importers:
> - installed directly on sys.meta_path
> - called via importer.find_module(fullname, path) (where path=None for
> a sys.path based import)
>
> Finders:
> - 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
> finder.find_module(fullname)
>
> Loaders:
> - 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
> alias.


But PathFinder is not an importer as it is not a finder *and* a loader:
http://docs.python.org/dev/glossary.html#term-importer .

_______________________________________________
Import-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/import-sig