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:
parent
8c349565e8
commit
cee29b46a1
|
@ -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
|
||||
--------------------
|
||||
|
||||
|
|
Loading…
Reference in New Issue