bpo-35486: Note Py3.6 import system API requirement change (GH-11540)

While the introduction of ModuleNotFoundError was fully backwards
compatible on the import API consumer side, folks providing alternative
implementations of `__import__` need to make an update to be
forward compatible with clients that start relying on the new subclass.



https://bugs.python.org/issue35486
This commit is contained in:
Nick Coghlan 2019-01-17 20:41:29 +10:00 committed by Miss Islington (bot)
parent 8c349565e8
commit cee29b46a1
2 changed files with 13 additions and 1 deletions

View File

@ -1737,7 +1737,8 @@ Python 3.6 and newer for other parts of the code).
if spec is not None:
break
else:
raise ImportError(f'No module named {absolute_name!r}')
msg = f'No module named {absolute_name!r}'
raise ModuleNotFoundError(msg, name=absolute_name)
module = importlib.util.module_from_spec(spec)
spec.loader.exec_module(module)
sys.modules[absolute_name] = module

View File

@ -2316,6 +2316,17 @@ Changes in the Python API
a :exc:`DeprecationWarning` in Python 3.6 and a :exc:`RuntimeError` in
Python 3.8.
* With the introduction of :exc:`ModuleNotFoundError`, import system consumers
may start expecting import system replacements to raise that more specific
exception when appropriate, rather than the less-specific :exc:`ImportError`.
To provide future compatibility with such consumers, implementors of
alternative import systems that completely replace :func:`__import__` will
need to update their implementations to raise the new subclass when a module
can't be found at all. Implementors of compliant plugins to the default
import system shouldn't need to make any changes, as the default import
system will raise the new subclass when appropriate.
Changes in the C API
--------------------