[Python-ideas] Use `isinstance` check during exception handling

[sjoerdjob at sjec.nl]

> Andrew Barnert via Python-ideas writes:
>  > Sjoerd Job Postmus <sjoerdjob at sjec.nl> wrote:
>
>  > > It might seem troublesome to change these locations to raise
>  > > actual instances instead of strings, but those might actually
>  > > just be hidden bugs just the same.
>
> No, I'm sure mostly they're not.  They're working code that has been
> there since the early days, perhaps a few from the 2.x days in
> modules.  Python is generally very conservative about changing working
> code.
>
>  > > Do you think anyone would object if I'd go over the code looking
>  > > for places where type(tstate->cur_value) != tstate->cur_type and
>  > > propose patches for these?
>
> I think, yes, though I don't know enough about it to object myself.
> Code churn of this kind is generally frowned upon, unless you can show
> that the risk of hidden bugs of the kind you refer to above is
> substantially greater than the risk that *you* will introduce bugs
> with your patches.

After digging more into the code, I concur. It's quite easy to make some
changes that break some stuff in this logic.

>  > It would be really nice if someone remembered _why_ the code is
>  > this way. It may be a performance issue—
>
> Or it could be bootstrapping -- it may be that "something" can be
> raised before the exception machinery is fully initialized.  (On
> reflection, that seems unlikely, if raise is available, BaseException
> probably is too.  But you never know. :)
>
> I would guess it was discussed, decided, and pronounced in one of the
> early Python 3 PEPs.  (I'm sure that for Python 2 it was purely an
> issue of backward compatibility.)

To all: thank you for at least considering my suggestion, and helping me
consider the pros and cons.

Even though I myself still think it would be a major benefit to change
from `issubclass` (or `exc in err.__mro__`) to `isinstance`, I do now see
that the changes needed to the Python codebase are quite substantial. The
consideration about third-party C-modules is also something to further
think about.

As I understand it now, the changes needed---and the possibility of
introduced bugs---outweigh the added benefit of such a change, at least
for now.

(Still, it send me along a nice cursory browse of the Python code base,
including the bytecode compiler and the evaluator. The compilation of the
bytecode for exception handling is nicely documented. To the author(s) of
that code: great job, it's very understandable!)