[Python-3000] callable()

[Guido van Rossum]

On 7/18/06, Michael Urman <murman at gmail.com> wrote:
> On 7/18/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> > I think that should be amended to "just use hasattr(obj. '__call__')
> > instead". That's what callable() will become equivalent to once
> > old_style classes are gone.
> >
> > Then it becomes a matter of whether it's worth having callable()
> > around as an alternative spelling. Those arguing in favour of
> > it would have to explain whether we should also have addable(),
> > subtractable(), mutiplyable(), indexable(), etc. etc. etc...
>
> I think if the proponents of removing callable had made it more
> obvious that hasatr(obj, '__call__') was a relatively equivalent
> option which served to make it obvious what its limitations were,
> there would have been fewer objections. Then I personally find the
> intent indication of callable(obj) vs hasattr(obj, '__call__') to be a
> good trade.

But I'm not proposing to use hasattr(obj, '__call__'). I'm basically
saying that the callable test has very little to do with whether the
later call will succeed, because we have no way to test the signature.

> As for callable() vs addable(), etc., the reason is obvious. Function
> calls very commonly have large side effects and are only rarely
> idempotent. The operations you mention are expected to have no side
> effects on the object. This makes a try/except much more palatable for
> addition, subscripting, etc. than for calling a function.

That's not at all obvious to me, and certainly I'm *not* proposing
surrounding everything with a try/except.

IMO the right solution lies in something like pychecker, not in adding
look-before-you-leap type checks, and certainly not in adding code
like

  try:
    do_something()
  except:
    print "An error occurred!"

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)