Repository navigation
Introduce MetaPathFinder.discover and PathEntryFinder.discover #139899
Description
Activity
Great. This way is like the method named "__find__" in my first plan. In my full plan, the message "No module named 'importlib.utill'. Did you mean: 'importlib.util'?" changes to "module 'importlib' has no child module 'utill'. Did you mean 'util'?", but it is up to everyone.
Now I use my test test_wrong_module_exception for the branch and use the folder structure like it (to avoid for long name):
aa\ __init__.py bbb.py aaa\ __init__.py bbb\ __init__.py cccc.pyHowever, the result is not expect. I will use my tool in friendly_module_not_found_error to find out where is wrong.
My fault :-( . The suggestion code is not there. I will try for that code.
OK. Now I sure it is a bug in that branch:
The right now implement on that branch cannot handle on relative import.
This is the question:
I suggest that the method
discoverand the code when finding the suggestion for ModuleNotFoundError should never import any modules.Yes, that's a bug on relative imports.
I suggest that the method
discoverand the code when finding the suggestion for ModuleNotFoundError should never import any modules.It triggers an import for the parent module, but it should never actually result in a new module being loaded. If the
ModuleNotFoundErroris triggering on the child, it means the parent was successfully imported, so it should always be insys.modulesalready.If the
ModuleNotFoundErroris triggering on the child, it means the parent was successfully imported, so it should always be insys.modulesalready.This statement is not always true. In relative import, when failed, the module will fail to load so finally it won't appear in
sys.modules.Which module? I am talking about the parent. In the current implementation, the parent is always in
sys.modules, we need its__path__. Taking your example,aaais insys.modules.For example,
aa.__init__want's to import modulebbfrom its__path__, but there is nobbthere, so it failed. It means that the code inaa.__init__failed. Any exceptions raised from the "__init__.py" will leads to that the module failed to load, so the parent moduleaawon't be insys.modules.
Right, that'll be true for regular packages, I suppose, when the error happens while we are executing the module. We can change the API to take a module spec instead.
I need to have a better look at this.
Thanks for the feedback!
Now there is another bug here:
If there is a module name that too long, the suggestion in this implement can give any suggestions on child module that exist, even if the name of the child module is vastly different from the suggestion. I suggest that the comparsion should be only limit to the child module name (because that the parent module can always be found).
More over, I suggest that don't suggest on the fullname. In relative import, the full module's name will be spreaded across multiple code files so that full-name suggestion need to be split.Is this basically a spec-like replacement for https://docs.python.org/3/library/pkgutil.html#pkgutil.iter_importers ?
Is this basically a spec-like replacement for https://docs.python.org/3/library/pkgutil.html#pkgutil.iter_importers ?
Seems not.
pkgutil.iter_importersfind the finders instead of submodules. More exactly,pkgutil.iter_importerscan simplify the logic to find "which finder find the parent package", but how to find the list of submodules depends on the finder itself.I'm fine with the idea, although we might want to use this as an opportunity to introduce protocols to importlib to move away from ABCs.
Reacted by Filipe Laíns and Gregory P. SmithWould it be more accurate to say that this could act as a spec-like replacement for
pkgutil.iter_modulesand the non-standardfinder.iter_modulesAPI it works with?If so, there may be an opportunity here to further advance #64138 by deprecating
pkgutil.iter_modulesand potentiallypkgutil.walk_packageswhile also turning them into thin wrappers aroundMetaPathFinder.discovercalls. Assuming I understand this correctly, it would be much clearer how users could replace usage of those functions with this new API in their code, at least compared to now, imo.- added a commit that references this issue
on Feb 5, 2026 - added a commit that references this issue
on Feb 19, 2026
Proposal:
In certain scenarios, such as implementing error suggestions for
ModuleNotFoundError, it would be helpful to have the ability to ask the finder to search for possible specs.I propose adding a new optional
discovermethod toMetaPathFinderandPathEntryFinder, as follows:Possibly, we could also add a helper function that searches
sys.meta_path, similarly toimportlib.util.find_spec. Although I don't think it is strictly necessary.This allows us to implement suggestions in
tracebackusing the import system abstractions — see https://github.com/FFY00/cpython/tree/ModuleNotFoundError-suggestions.Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs