[Python-Dev] concerns regarding callable() method (original) (raw)

Phillip J. Eby pje at telecommunity.com
Mon Apr 9 00🔞54 CEST 2007

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.

More information about the Python-Dev mailing list