On 5/6/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 5/6/06, Collin Winter <[EMAIL PROTECTED]> wrote: > > On 5/5/06, Guido van Rossum <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
