diff options
author | Nick Coghlan <ncoghlan@gmail.com> | 2019-01-17 20:41:29 +1000 |
---|---|---|
committer | Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com> | 2019-01-17 02:41:29 -0800 |
commit | cee29b46a19116261b083dc803217aa754c7df40 (patch) | |
tree | b34027910cb04d187121d7371bbdbfd749185087 | |
parent | 8c349565e8a442e17f1a954d1a9996847749d778 (diff) | |
download | cpython-git-cee29b46a19116261b083dc803217aa754c7df40.tar.gz |
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
-rw-r--r-- | Doc/library/importlib.rst | 3 | ||||
-rw-r--r-- | Doc/whatsnew/3.6.rst | 11 |
2 files changed, 13 insertions, 1 deletions
diff --git a/Doc/library/importlib.rst b/Doc/library/importlib.rst index 3c9a99abf9..23831c7584 100644 --- a/Doc/library/importlib.rst +++ b/Doc/library/importlib.rst @@ -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 diff --git a/Doc/whatsnew/3.6.rst b/Doc/whatsnew/3.6.rst index 936ea2dc32..3f5f5200f1 100644 --- a/Doc/whatsnew/3.6.rst +++ b/Doc/whatsnew/3.6.rst @@ -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 -------------------- |