Commit cee29b46 authored by Nick Coghlan's avatar Nick Coghlan Committed by Miss Islington (bot)

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
parent 8c349565
......@@ -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
......
......@@ -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
--------------------
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment