summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>2019-01-17 17:11:09 -0800
committerNed Deily <nad@python.org>2019-01-17 20:11:09 -0500
commit1edb3dc6ff70db88a7e89586578e58a86ee0e75e (patch)
treeb6efc089063907fb1dd24725a619104354f44b03
parentbpo-35525: Correct the argument name for NNTP.starttls() (GH-11310) (GH-11417) (diff)
downloadcpython-1edb3dc6ff70db88a7e89586578e58a86ee0e75e.tar.gz
cpython-1edb3dc6ff70db88a7e89586578e58a86ee0e75e.tar.bz2
cpython-1edb3dc6ff70db88a7e89586578e58a86ee0e75e.zip
bpo-35486: Note Py3.6 import system API requirement change (GH-11540) (GH-11588)
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 (cherry picked from commit cee29b46a19116261b083dc803217aa754c7df40) Co-authored-by: Nick Coghlan <ncoghlan@gmail.com>
-rw-r--r--Doc/library/importlib.rst3
-rw-r--r--Doc/whatsnew/3.6.rst11
2 files changed, 13 insertions, 1 deletions
diff --git a/Doc/library/importlib.rst b/Doc/library/importlib.rst
index 25055f7ce39..30293d4d985 100644
--- a/Doc/library/importlib.rst
+++ b/Doc/library/importlib.rst
@@ -1488,7 +1488,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 009584428fc..bd5c6340130 100644
--- a/Doc/whatsnew/3.6.rst
+++ b/Doc/whatsnew/3.6.rst
@@ -2328,6 +2328,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
--------------------