[Python-Dev] concerns regarding callable() method

[Phillip J. Eby]

At 08:01 PM 4/8/2007 +0400, Alexey Borzenkov wrote:
>On 4/8/07, Guido van Rossum <guido at python.org> wrote:
> > On 4/8/07, Paul Pogonyshev <pogonyshev at gmx.net> wrote:
> > > Guido van Rossum wrote:
> > > > What if someone passes a callable that doesn't have the expected 
> signature?
> > > Well, I don't know a way to catch such situations now, so removing
> > > callable() will not make it worse (even if you don't know about hasattr
> > > trick above.)
> > My point is that it's futile to use callable() -- even if it passes,
> > you have no assurance that you actually have a valid callback. So why
> > bother with it at all? It's counter to the spirit of Python. If
> > someone passes you a bad callback, they will see a traceback when you
> > call it. Then they fix their program. That's how it's supposed to
> > work.
>
>But what if you need to do different things based on argument is
>callable or not?

Then delegate that behavior to the object using adaptation or a generic 
function.  That is, use *table-driven* code, rather than if-then based code.


>Take for example "Dependency Injection" recipe:
>
>     http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413268
>
>It uses callable to differentiate whether it needs to use object as
>singleton or to instantiate it on each request.

And that's a *bad* thing.  What if I want to have a callable singleton?  Or 
what if I want to have a singleton that gets notified of each request?

With table-driven code (adaptation, generic functions) I can support the 
first case by reregistering an existing handler, and the second by 
registering my own handler.

If-then based introspection is harmful here, because it's an attempt to 
*guess* what should be done with the object.  Explicit is better than 
implicit, and it's better not to guess.

callable(), like hasattr() or any other "interface probing" is essentially 
an attempt to guess at the callers intent, instead of providing a 
reasonable default that they can override.