<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 31 May 2018 at 14:47, Danilo J. S. Bellini <span dir="ltr"><<a href="mailto:danilo.bellini@gmail.com" target="_blank">danilo.bellini@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The idea is to allow catching exceptions beyond checking their MRO,<br>using a class that checks the exception instance by implementing<br>a custom <span style="font-family:monospace,monospace">__instancecheck__</span>.</div></blockquote><div></div><div><br></div><div>The exception machinery deliberately attempts to avoid instantiating exception objects whenever it can, but that gets significantly more difficult if we always need to create the instance before we can decide whether or not the raised exception matches the given exception handler criteria.</div><div><br></div><div>So quite aside from any philosophy-of-design questions, we're unlikely to ever implement this simply for laziness-of-evaluation reasons. (There are already lots of circumstances that force instantiation - that doesn't mean we're keen to add more)<br></div><div><br></div>Cheers,</div><div class="gmail_quote">Nick.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>P.S. There's a somewhat related issue aimed at getting ABCs to work 
correctly as exception handlers, although that still sticks to the principle that exception handler checks solely consider the exception type, not its value: <a href="https://bugs.python.org/issue12029">https://bugs.python.org/issue12029</a><br></div></div><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>