I really like the idea of a exception type check, and I think this can still be done in a pythonic way.
I think for the most part their is merit in just ignoring the type of exceptions entirely, then in an except block, the ide can list all the expected errors that might happen in the try block, and then the developer can either handle one or more of the errors as shown by the ide, or handle whatever error they want to. This will narrow down for the developer what errors they could expect, and reduce the overhead of reading documentation.
Often there are exception that can explicitly be handled, but go unnoticed, either because of poor documentation or because of it’s obscurity in development situation or even because you forgot.
Then the unhandled errors can just go up the chain. So you can just write however you want, but when handling error you’ll get a little extra help.
Also for things like __next__ and contextlib’s contextmanager, it can help a little, by giving you a consice description of what error you should raise.
It’s almost always easier for me to code if I don’t need to read documentation to do what I want to do and if the ide can give me appropriate suggestions depending on context, but not restrict me too much in terms of how I write my code. Which is why I like python so much. And this can help without really adding much in terms of restriction.
As I understand, this wouldn’t be the traditional checked exception, but a very loose variant of the same.
One last note, which isn’t as important, I often just write down a bunch of code and document it only after I’m done writing all of it, so having an extra help on handling error that was thrown in another file, can very much help me.