On 29 June 2017 at 05:14, Nathaniel Smith <njs@pobox.com> wrote:
What about modules that want to raise ImportError to indicate that they aren't available on the current system, perhaps because some of their dependencies are missing? For example, 'import ssl' should raise an ImportError if 'ssl.py' is present but '_ssl.so' is missing; the existence of '_ssl.so' is an internal implementation detail. And perhaps 'import trio.ssl' should raise ImportError if 'ssl' is missing. (Historically not all systems have openssl available, so this is a common situation where existing libraries contain ImportError guards.)
With PEP 479 there was a different and better way to generate a StopIteration if you wanted one (just 'return'). Here I'm afraid existing projects might actually be relying on the implicit exception leakage in significant numbers :-/
Hence "it may be worth filing an RFE so we can discuss the implications", rather than "we should definitely do it". The kinds of cases you cite will already fail for import guards that check for "exc.name == 'the_module_being_imported'" though, so I'd be OK with requiring modules that actually wanted that behaviour to do: try: import other_module except ImportError as exc: raise ImportError("other_module is missing", name=__name__, path=__file__) from exc The guard around exec_module() would then look something like: try: loader.exec_module(mod) except ImportError as exc: if exc.name == mod.__name__: raise msg = f"Failed to import '{exc.name}' from '{mod.__name__}'" raise RuntimeError(msg) from exc Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia