On 29 June 2017 at 05:14, Nathaniel Smith <n...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
