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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/J7K4OQGK3Z3M76MPJV2D5DIPON4NZRXS/ Code of Conduct: http://python.org/psf/codeofconduct/
