Note that I've flagged this for Python 3.6 so that https://docs.python.org/3.6/whatsnew/3.6.html#porting-to-python-3-6 will get updated.

(cc @ned-deily)

@python/import-team One thing to check here is that I think I'm right that anyone writing meta_path importers and PathFinder path hooks still doesn't need to worry about raising ModuleNotFoundError themselves, since they signal "didn't find it" by returning None in place of a loader or module spec (depending on exactly which plugin API we're talking about), and hence it's only full replacements of __import__ that need to worry about emitting ModuleNotFoundError in the appropriate places.

However, it's also possible that this change may uncover latent plugin defects where the plugin is raising ImportError directly when it should be returning None and letting the import system handle converting that to an exception if none of the available hooks produce a usable result.

If you want to be extra-thorough, the Approximating importlib.import_module() example in the importlib docs could stand to be updated to raise ModuleNotFoundError instead of ImportError.

Otherwise LGTM and your assessment that nothing in importlib as exposed publicly needs updating seems accurate (i.e. it's the loaders that will raise ImportError and none of those changed).

@brettcannon Example updated. It turns out that just setting name=module_name doesn't work, as it leaves the exception with a blank message.

@ncoghlan: Status check is done, and it's a success ✅ .

Thanks @ncoghlan for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7.
🐍🍒⛏🤖

GH-11587 is a backport of this pull request to the 3.7 branch.

GH-11588 is a backport of this pull request to the 3.6 branch.