<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On Jun 28, 2017 6:26 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 28 June 2017 at 21:48, Sven R. Kunze <<a href="mailto:srkunze@mail.de">srkunze@mail.de</a>> wrote:<br>
> As it was snipped away, let me ask again:<br>
><br>
> I don't see how this helps differentiating shallow and nested exceptions<br>
> such as:<br>
><br>
> try:<br>
>     with exception_guard(ImportError):<br>
>         import myspeciallib<br>
> except RuntimeError: # catches shallow and nested ones<br>
>     import fallbacks.MySpecialLib as myspeciallib<br>
<br>
</div>There are two answers to that:<br>
<br>
1. In 3.3+ you can just catch ImportError, check "<a href="http://exc.name" rel="noreferrer" target="_blank">exc.name</a>", and<br>
re-raise if it's not for the module you care about<br>
<br>
2. There's a reasonable case to be made that importlib should include<br>
an ImportError -> RuntimeError conversion around the call to<br>
loader.exec_module (in the same spirit as PEP 479). That way, in:<br>
<br>
    try:<br>
        import myspeciallib<br>
    except ImportError:<br>
        import fallbacks.MySpecialLib as myspeciallib<br>
<br>
any caught ImportError would relate to "myspeciallib", while uncaught<br>
ImportErrors arising from *executing* "myspeciallib" will be converted<br>
to RuntimeError, with the original ImportError as their __cause__.<br>
<br>
So it would make sense to file an RFE against 3.7 proposing that<br>
behavioural change (we couldn't reasonably do anything like that with<br>
the old `load_module()` importer API, as raising ImportError was how<br>
that API signalled "I can't load that". We don't have that problem<br>
with `exec_module()`).<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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.)</div><div dir="auto"><br></div><div dir="auto">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 :-/</div><div dir="auto"><br></div><div dir="auto">More generally, my impression is that this is one of the reasons why exceptions have fallen out of favor in more recent languages. They're certainly workable, and python's certainly not going to change now, but they do have these awkward aspects that weren't as clear 20 years ago and that now we have to live with.</div><div dir="auto"><br></div><div dir="auto">-n</div></div>