Steven D'Aprano writes:
Proposal: add a new exception, ParameterError, for parameter errors. For backwards compatibility it would have to be a subclass of TypeError.
To me, that name evokes all kinds of things that linters and mypy do, but the Python interpreter can't or shouldn't. FunctionSignatureError, maybe? I'm not against the proposal, but for the sake of my own curiosity: ISTM that most use cases for this distinction (eg, functionals like reduce) should be left up to mypy, or to developers reading the error messages. A matter of taste, I guess, but assuming that leaves your original use case, feature testing. But the feature test is going to be done with a test case controlled by the developer, not taken from the environment. Is it common that TypeErrors are ambiguous in such a context?
But for stability reasons (what if the error messages are localised, or change in the future?), we could give the exception a "reason" attribute, with a documented stable ID,
I'm fine on that, but please give it human-readable values. Steve