1. add to importlib.machinery
2. register on importlib.abc.Finder

patch in a moment.

I'm not sure why some finders are named "Finder" and others "Importer". It makes things confusing.

The importers can both find and load modules (e.g. BuiltinImporter defines both find_module() and load_module()), while the finders only find modules (e.g. only define find_module()). It's defined in the glossary, so maybe more links to that would help.

> The importers can both find and load modules (e.g. BuiltinImporter
> defines both find_module() and load_module()), while the finders only
> find modules (e.g. only define find_module()).

Ah, fair enough. I thought loader objects were always distinct from
finders.

Also, WindowsRegistryImporter is misnamed.  It should be WindowsRegistryFinder (see issue15502).  Depending on the patch there, I'll update the one here.

I guess the real question here is if anyone has problems with adding WindowsRegistryFinder to importlib.machinery (and to the importlib docs).  If it should stay private than I'd like to throw a _ on the name of the class.  The change to importlib.abc would likely stay either way.

It should be exposed (i.e. if SourcelessFileLoader is documented and exposed then so should WindowsRegistryFinder).

We'll also want to add this to the inheritance tests in test_importlib.test_abc

This didn't close automatically (I assume the open dependency upset matters, since it also prevented me from closing it manually the first time).

Applied to trunk in http://hg.python.org/cpython/rev/a1ac1e13c5a0

(including the rename from #15502)