Guido's new method definition idea

Andreas Waldenburger geekmail at usenot.de
Sun Dec 7 18:27:21 CET 2008


On Sat, 6 Dec 2008 23:21:04 -0800 (PST) Lie <Lie.1296 at gmail.com> wrote:

> I think we have to test this on newbies. [snip]
> 
Now that's talking like a programmer!

Ideas on how such a survey could be conducted? Anyone?


> If this dead horse is revived because of that reason, then I'd go with
> changing the error message to something that is less confusing to
> newbies[1].
+ googol


> I remember being tripped with the (thinking that python
> miscounted the number of argument) when I was new. This has the
> advantage of backward compatibility and no syntax change, just less
> misleading error message.
> 
> [1] anything could work, but I like this one: (c is an instance of
> class C)
> if the code is: c.foo(...), Error: "TypeError: c.foo() takes exactly 3
> argument"
> while if the code is: C.foo(...), Error: "C.foo() takes exactly 4
> arguments"
> You can implement c.foo as a curried C.foo function, catch C.foo's
> TypeError exception then reraise it as c.foo exception.
I'm not sure that I'd find that less confusing. Because a c.foo()
*does* take four arguments, not three. It's just that the first one is
implicit (Right?).


How about:

"TypeError: c.foo() takes exactly 3 arguments in addition to
the implicit instance reference."

or

"TypeError: c.foo() takes exactly 4 arguments (5 given, including the
implicit instance reference)"

... or something less kludgy in that general direction. This would
explain exactly what is wrong.

/W

-- 
My real email address is constructed by swapping the domain with the
recipient (local part).



More information about the Python-list mailing list