[Python-3000] callable()

[Andrew Koenig]

> 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.

Doesn't matter.  The point is not whether I know how to test for a
capability, but whether the test will continue to work in future
implementations.  Having an explicitly defined abstraction for such a test
is useful for that reason (among others).

> 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.

Most code is concerned with checking zero capabilities.

> 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.

I think you've just proved my point.  Do the expressions you've written
actually check for hashability?  Are you sure?  Try it with obj=[42]

> 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.

On the other hand, once we have the notion of capability, it is not hard to
think of other capabilities that objects might have that are not easily
testable at present.  One example that comes to mind is "< defines a total
ordering over objects of this type."  That's something that's not
automatically testable, but I could imagine it being provided by convention
as part of a library.

> >         * 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.

Whenever there are side effects, it is nice to have a way of deferring those
side effects until it is absolutely impossible to avoid them.