This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Arfrever, barry, brett.cannon, eric.smith, eric.snow, georg.brandl, ncoghlan
Date 2012-08-01.05:45:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1343799932.73.0.48330159311.issue15502@psf.upfronthosting.co.za>
In-reply-to
Content
Reading the 3.3 What's New reminded me that we aren't really as free to redefine this terminology as we might hope (or as I claimed on the previous issue). We can still try, of course, but the PEP 302 naming scheme has been around for 10 years, and there are plenty of guides and other things that assume that the things on the meta path and things returned by path hooks are both finders. That's actually reasonable, since the key role of both is to find a module loader given a module name. They differ in API details, but they fundamentally do the same thing. Better to go with the flow, especially given how close we are to release.

As far as the implementation goes:

+1 for renaming WindowsRegistryImporter to WindowsRegistryFinder

-1 on breaking any find_module implementations. Backwards compatibility requirements still apply to the importlib API - while the default import system won't call FileFinder.find_module() any more, third party import reimplementations are still free to do so.
History
Date User Action Args
2012-08-01 05:45:33ncoghlansetrecipients: + ncoghlan, barry, brett.cannon, georg.brandl, eric.smith, Arfrever, eric.snow
2012-08-01 05:45:32ncoghlansetmessageid: <1343799932.73.0.48330159311.issue15502@psf.upfronthosting.co.za>
2012-08-01 05:45:32ncoghlanlinkissue15502 messages
2012-08-01 05:45:29ncoghlancreate