On Wed, Mar 4, 2020 at 9:58 PM Steven D'Aprano <st...@pearwood.info> wrote: > > The important thing is to be able to programmatically > distinguish the case where arguments don't match the parameters from the > case where an argument is the wrong type. >
Or where you're trying to call something that isn't callable. There are several distinct "phases" to calling a function, and TypeError could come up from any of them: >>> "spam"() <stdin>:1: SyntaxWarning: 'str' object is not callable; perhaps you missed a comma? Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'str' object is not callable >>> len(1, 2) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: len() takes exactly one argument (2 given) >>> len(1) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: object of type 'int' has no len() Being able to easily distinguish "that isn't callable" from "the parameters don't line up" from "the function, during execution, raised TypeError" would be useful. So, I agree that the bikeshed is of value here. As to colour, I'd be (weakly) inclined toward: 1) ParameterError and maybe UncallableError as well 2) Type flags with class constants eg ParameterError.TOO_MANY Even if TOO_MANY is technically just the integer 2 (as opposed to an IntEnum), encouraging people to use that will make it a lot easier to read. C code can use a #define for maximum performance, and then the cost of looking up the attribute is paid only if the exception is caught AND checked for that status - minimal overhead on creation. ChrisA _______________________________________________ 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/D6ZDQKMFMGWVGKDYWQVPE3WYPECWRBD2/ Code of Conduct: http://python.org/psf/codeofconduct/
