[Skip Montanaro, with an expression that may raise TypeError for any of several distinct reasons, and wants to figure out which one after the fact] The existing exception machinery is sufficiently powerful for building a solution, so nothing new is needed in the language. What you really need here is an exhaustive list of all exceptions the language can raise, and when, and why, and a formally supported "detail" field (whether numeric id or string or whatever) that you can rely on to tell them apart at runtime. There are at least a thousand cases that need to be so documented and formalized. That's why not a one of them is now <0.9 wink>. If P3K is a rewrite from scratch, a rational scheme could be built in from the start. Else it would seem to require a volunteer with even less of a life than us <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4