[Python-3000] Changing function-related TypeErrors

Collin Winter collinw at gmail.com
Fri May 5 21:30:14 CEST 2006


On 5/1/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> The Type Error is actually referring to the type of 'foo' - the code is
> clearly expecting it to be something with a different __call__ signature.
>
> However, for things like functions, there's nothing wrong with the type of the
> supplied object. For functions, the problem is actually a Value Error, in that
> the signature of that particular function *instance* is wrong.

Is there anywhere else in Python where the type of an object isn't
checkable with isinstance()? While I agree this situation can be
viewed as a problem with the function's type, it seems odd to take
this view, given Python's current attitude toward typing. If this were
a language like Haskell or ML, where we were used to talking of
function types like (Int -> Int -> [Int]), then, yes, it should be a
TypeError.

Put another way, saying an invalid argument set indicates an error in
the function type feels somewhat equivalent to saying that a list of
floats in place of an expected list of ints is a problem with the list
(rather than its elements). In Haskell, this would make sense, but it
seems unintuitive in Python.

> I don't really have a preference here - the current error is a little obscure,
> but I'm not sure fixing it is worth the effort of adding a new exception type.

I would think that eliminating this obscurity is worth the minimal
overhead of a single new exception class. Really, how often do people
go reading through exceptions.c?

Collin Winter


More information about the Python-3000 mailing list