Re: PEP 420 issue: extend_path

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia