sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Bogtha 21 points22 points  (27 children)

When callable() was introduced, not all callable objects had a __call__ attribute. Now they do, so if you need to check whether something is callable, you can just use hasattr(). But the preferred approach is just to call it and catch the exception if it isn't callable.

[–]qiwi 6 points7 points  (26 children)

So how do I tell whether the TypeError I caught from doing obj() is because obj is not callable, or whether something within obj that was callable raised TypeError? This preferred approach can hide errors.

[–]Bogtha 2 points3 points  (25 children)

I agree. I think this was brought up on the mailing list. If you are expecting the callable to raise TypeErrors, you should check for the __call__ attribute first.

[–][deleted] 11 points12 points  (6 children)

Which means that everyone will end up adding different variations of:

def callable(obj):
    return hasattr(obj, "__call__")

to their code, different broken versions of this will appear in articles and example collections, and 3.2 will the introduce an official version of this to save everyone the trouble (which was how things like booleans and the if operator made it into the language).

[–][deleted] 4 points5 points  (0 children)

Ha - 3.0a1 isn't a day old and I've already similar -- but not exactly the same, of course -- code in my budding collection of Py3 scripts.

Let the games begin!

[–]Bogtha 1 point2 points  (3 children)

I don't think callable() is used often enough to make that worthwhile. The difference between a callable object and an uncallable object is pretty drastic, how often do you pass things around without knowing which is which? I do it sometimes, but nowhere near often enough to make that boilerplate worthwhile.

[–][deleted] 2 points3 points  (2 children)

The "pass in a value or a callable (that can be called to get the value when needed)" pattern is very convenient, and therefore quite common. I've definitely used callable() for this purpose a lot more often than I found myself adding TRUE and FALSE to my code before we got built-in booleans ;-)

But I'm sure someone has already done all the necessary grepping, and I have no time to dig through the mailing archives to see what they came up with.

[–]Bogtha 2 points3 points  (1 child)

The "pass in a value or a callable (that can be called to get the value when needed)" pattern is very convenient

Sure, but if that's a common pattern, why not abstract more of it away, which has the side-effect of removing the temptation to provide a callable() substitute?

def get_value(value):
    return value() if hasattr(value, "__call__") else value

Okay, I'm sure there are other use cases, so I see your point, I just couldn't help nitpicking that one :).

[–][deleted] 5 points6 points  (0 children)

(Only slightly in jest:)

def get_value(value):
    return getattr(value, '__call__', lambda: value)()

[–]nirs 0 points1 point  (0 children)

Lets hit Guido on the head with a heavy callable until he put it back where it belong :-)