[Python-3000] callable()

[Michael Urman]

On 7/26/06, Andrew Koenig <ark-mlist at att.net> wrote:
>         * Uniform -- the general form of the inquiry does not
>                 depend on the particular capability being inquired about

While this makes sense from the perspective you mention, paraphrased
as "different objects have different capabilities, and I want to query
what capabilities this object has," I'm not convinced that any but the
most uncommon uses involve enumerating the capabilities of an object.
And those users are likely to be experts of the implementation.

I would expect that code is more often concerned with checking no more
than one or two capabilities, letting the implicit check of a raised
exception do the rest. Since the times you would use __call__ and the
times you would use __hash__ are so different, it seems reasonable to
me that the corresponding capability check might be different.

Case in point, I almost never use hash() directly; I delegate that to
the dict I'm using. Whether the check were spelled "type(obj).__hash__
is not None" or "hasattr(type(obj).__hash__, "__call__")" or "try: ...
except ...: ..." I wouldn't care; I've never needed to write his
myself, and don't expect to.

Is there code that needs to check the hashability? Sure. Does this
code also need to check callability? Maybe. How about addability?
Subtractibility? I doubt it.

>         * Free of side effects

This is an ideal I agree with for some uses, although again I prefer
the software version of idempotence (calling it once or many times has
the same result) to side-effect-free. For many capabilities, the
underlying implementation is expected to be idempotent, so I see no
reason to require a separate idempotent check. We're adults here; if
an implementation doesn't follow convention, it does so for a reason,
and accepts the risk that someone may accidentally use it the
conventional way.

Michael
-- 
Michael Urman  http://www.tortall.net/mu/blog