On 5/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 5/5/06, Collin Winter <[EMAIL PROTECTED]> wrote: > > On 5/1/06, Nick Coghlan <[EMAIL PROTECTED]> 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 _______________________________________________ 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
