[Python-3000] Changing function-related TypeErrors

Collin Winter collinw at gmail.com
Sat May 6 16:09:59 CEST 2006


On 5/5/06, Guido van Rossum <guido at python.org> wrote:
> On 5/5/06, Collin Winter <collinw at gmail.com> wrote:
> > 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()?
>
> Yes, it's called duck typing.
>
> I'm not sure it's worth distinguishing call signature errors from
> other type errors; there's already a gray area where sometimes a
> TypeError is reported as an AttributeError or vice versa.

I think that this way of looking at call errors is fairly divorced
from the way programmers actually work. If you look at a call error as
a type error (or ValueError), then you're saying that the call site
arguments are correct -- you've simply used the wrong function. But
what process do you go through to fix a call-site error? Do you change
function X to match the call site or write a function with the proper
signature that wraps function X? Of course not. You change the call
site to match the signature.

Collin Winter


More information about the Python-3000 mailing list