[Python-3000] Changing function-related TypeErrors

[Collin Winter]

On 5/6/06, Guido van Rossum <guido at python.org> wrote:
> On 5/6/06, Collin Winter <collinw at gmail.com> wrote:
> > On 5/5/06, Guido van Rossum <guido at python.org> wrote:
> > > 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.
>
> Actually, it's symmetric. When Python issues a TypeError for 'a'+1,
> which argument is wrong? It depends! The same is true in general when
> the arguments don't match the function. You could have made a typo and
> called a different function than you meant to call.

Which is more common: mistyping a single keyword or omitting an
argument in a function call (wrong arguments, right function), or a
mistyping a function name such that you miraculously end up with a
function anyway (right arguments, wrong function)?

Python shouldn't pander to people who name functions 'aaa', 'aab', 'aac', ...

> Or it could be a method of a different object than you expected.

Then it's the type of the object that's erroneous, no?

> You could have mis-implemented an overriding method.

True, but I still think that calling this an ArgumentError makes more
sense: it lets you know that the arguments don't match the signature.

> Your assumption is that when you get an argument type error it's
> always a bug in the call site. That's simply not true.

Your assumption is that the call site should be trusted over the
function's signature. I prefer to trust the thing I write once, rather
than the thing I write dozens of times.

I will concede that introducing ArgumentError might indeed result in
some false positives in relatively rare cases. However, I think this
is acceptable in exchange for a more intuitive error message in the
vast majority of cases.

This -- more intuitive error messages -- is really what I'm after, and
while you may think of type of "def foo(a, b, c):..." as "a function
with three required arguments", I'd wager that most Python
programmers, if asked what type foo has, would say simply, "it's a
function".

Collin Winter