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 martin.panter
Recipients Oren Milman, docs@python, eric.araujo, jaysinh.shukla, kushal.das, martin.panter, ncoghlan
Date 2016-07-16.09:50:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1468662649.25.0.216847201784.issue20842@psf.upfronthosting.co.za>
In-reply-to
Content
I still think the links are too dense. Three links to the same term in two short paragraphs is too much. Do you think it would be okay to just link the first occurrence for pkgutil.ImpImporter?

Also, there is still a problem at least the definition of “finder” used by the ImpImporter documentation. In PEP 302, “a finder object has a single method: finder.find_module(fullname, path=None)”. This seems to be a pretty good description of the ImpImporter API. However, by dropping the reference to PEP 302, and linking to the glossary definition, we are suggesting that ImpImporter implements importlib.abc.MetaPathFinder and/or importlib.abc.PathEntryFinder. Both these APIs require some sort of find_spec() method, which is not provided by ImpImporter.

As I see it, either Python’s “finder” glossary entry should be adjusted to accommodate PEP 302, or we should retain the PEP 302 reference and not point at the wrong definition of “finder”.
History
Date User Action Args
2016-07-16 09:50:49martin.pantersetrecipients: + martin.panter, ncoghlan, eric.araujo, docs@python, kushal.das, Oren Milman, jaysinh.shukla
2016-07-16 09:50:49martin.pantersetmessageid: <1468662649.25.0.216847201784.issue20842@psf.upfronthosting.co.za>
2016-07-16 09:50:49martin.panterlinkissue20842 messages
2016-07-16 09:50:48martin.pantercreate