Callable assertion?

[Roy Smith]

I've got a function which gets passed a call-back function as a
parameter. I want to check to make sure the thing passed in is indeed
callable. Is:

assert '__call__' in dir (param)

the right thing to do, or is there something cleaner? Will that work
for all callable values of param, regardless if it's a static function,
class method, built-in, etc?

I'm running 2.3.1. Backward compatability isn't particularly an issue
for me, but I guess it would be nice to know how far back in time this
works.

[A.M. Kuchling]

On Sun, 05 Oct 2003 08:55:45 -0400,
Roy Smith <ro*@panix.com> wrote:

the right thing to do, or is there something cleaner? Will that work
for all callable values of param, regardless if it's a static function,
class method, built-in, etc?

There's a callable(param) built-in function, dating back to Python 1.2.

--amk

[Roy Smith]

In article <wM********************@speakeasy.net>,
"A.M. Kuchling" <am*@amk.ca> wrote:

On Sun, 05 Oct 2003 08:55:45 -0400,
Roy Smith <ro*@panix.com> wrote:

the right thing to do, or is there something cleaner? Will that work
for all callable values of param, regardless if it's a static function,
class method, built-in, etc?

There's a callable(param) built-in function, dating back to Python 1.2.

--amk

Ah. That's exactly what I was looking for! The docs say:

"Return true if the object argument appears callable, false if not. If
this returns true, it is still possible that a call fails, but if it is
false, calling object will never succeed."

What does "appears callable" mean? Under what circumstances would
callable(foo) return True, yet foo() would fail?

[Terry Reedy]

"Roy Smith" <ro*@panix.com> wrote in message
news:ro***********************@reader2.panix.com.. .

I've got a function which gets passed a call-back function as a
parameter. I want to check to make sure the thing passed in is indeed callable.

The acid test is to try calling it:

try: param()
except TypeError, msg: <do whatever>

You can check that msg.endswith('not callable') if you want but I
don't know the stability of the error message.

Terry J. Reedy

[Roy Smith]

In article <h5********************@comcast.com>,
"Terry Reedy" <tj*****@udel.edu> wrote:

"Roy Smith" <ro*@panix.com> wrote in message
news:ro***********************@reader2.panix.com.. .

I've got a function which gets passed a call-back function as a
parameter. I want to check to make sure the thing passed in is

indeed

callable.

The acid test is to try calling it:

try: param()
except TypeError, msg: <do whatever>

The problem there is that it really calls the function! I want to test
the paramater for correctness in my constructor, but I don't actually
want it called until it's supposed to be called. Calling the function
to prove it's callable is kind of like checking to see if a gun's safety
is on by pulling the trigger :-)

Not to mention that param might indeed be callable and the TypeError is
being generated (and not caught) somewhere further down.

[Gonçalo Rodrigues]

On Sun, 05 Oct 2003 10:20:11 -0400, Roy Smith <ro*@panix.com> wrote:

In article <wM********************@speakeasy.net>,
"A.M. Kuchling" <am*@amk.ca> wrote:

On Sun, 05 Oct 2003 08:55:45 -0400,
Roy Smith <ro*@panix.com> wrote:

> the right thing to do, or is there something cleaner? Will that work
> for all callable values of param, regardless if it's a static function,
> class method, built-in, etc?

There's a callable(param) built-in function, dating back to Python 1.2.

--amk

Ah. That's exactly what I was looking for! The docs say:

"Return true if the object argument appears callable, false if not. If
this returns true, it is still possible that a call fails, but if it is
false, calling object will never succeed."

What does "appears callable" mean? Under what circumstances would
callable(foo) return True, yet foo() would fail?

An extreme and artificial example:

class FakeCallable(object): .... def __call__(self, *args, **kwargs):
.... raise TypeError("My only purpose in life is to trick
the Python interpreter.")
.... a = FakeCallable()
callable(a) True a() Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "<interactive input>", line 3, in __call__
TypeError: My only purpose in life is to trick the Python interpreter.

Best,
G. Rodrigues

[Lulu of the Lotus-Eaters]

"Terry Reedy" <tj*****@udel.edu> wrote previously:
|The acid test is to try calling it:
|try: param()
|except TypeError, msg: <do whatever>

This is usually a bad idea though. Many, if not most, things you call
can either have side effects and/or consume non-trivial resources (time,
memory, especially).

For example, you don't want to change state by making a call if you know
you are not ready for that state change until something else happens.
But you may want to know whether 'param' is callable before you bother
with the setup code.

Yours, Lulu...

--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.

[Lulu of the Lotus-Eaters]

"Terry Reedy" <tj*****@udel.edu> wrote previously:
|The acid test is to try calling it:
|try: param()
|except TypeError, msg: <do whatever>

This is usually a bad idea though. Many, if not most, things you call
can either have side effects and/or consume non-trivial resources (time,
memory, especially).

For example, you don't want to change state by making a call if you know
you are not ready for that state change until something else happens.
But you may want to know whether 'param' is callable before you bother
with the setup code.

Yours, Lulu...

--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.

[Terry Reedy]

"Roy Smith" <ro*@panix.com> wrote in message
news:ro***********************@reader2.panix.com.. .

In article <h5********************@comcast.com>,
"Terry Reedy" <tj*****@udel.edu> wrote:

The acid test is to try calling it:

try: param()
except TypeError, msg: <do whatever>
The problem there is that it really calls the function!

Of course. You only do this test when you actually want the function
called.
I want to test
the paramater for correctness in my constructor,
I was afraid of that ;-).
but I don't actually
want it called until it's supposed to be called. Calling the function to prove it's callable is kind of like checking to see if a gun's safety is on by pulling the trigger :-)
But it is the Python way. Someone recently asked how to test if one
can connect to a site without actually connecting and Alex M. gave
much the same answer I did. The frequent question "how can I tell if
I can read a file without actually reading it" gets the stock answer
'you can't, not for sure', just as iscallable is 'not for sure'.
Sorry, time-varying reality and the possibility of lies sometimes
bites
Not to mention that param might indeed be callable and the TypeError is being generated (and not caught) somewhere further down.

That is why I suggested looking at the message, although you are
right, the same message could also be passed up.

Terry J. Reedy

[Terry Reedy]

"Lulu of the Lotus-Eaters" <me***@gnosis.cx> wrote in message
news:ma*********************************@python.or g...

"Terry Reedy" <tj*****@udel.edu> wrote previously:
|The acid test is to try calling it:
|try: param()
|except TypeError, msg: <do whatever>

This is usually a bad idea though.
I disagree. The OP previously got the iscallable() answer, with the
caveat that True may be a lie, and I posted in that context. One
might still want to wrap the actual call in a try block. It is the
same for reading files or making socket connections. No matter what
pre-info one gathers, the acid test is to try to do it, and a careful
coder will prepare for possible failure.
Many, if not most, things you call can either have side effects and/or consume non-trivial resources (time, memory, especially).
For example, you don't want to change state by making a call if you know you are not ready for that state change until something else happens.

Of course. I assumed the OP already knows this.
But you may want to know whether 'param' is callable before you bother with the setup code.

Of course, but regardless of 'want', you cannot know for sure, as 1 or
2 others have said and shown (see Rodriguez' post).

Terry J. Reedy

[Peter Hansen]

Roy Smith wrote:

I want to test
the paramater for correctness in my constructor, but I don't actually
want it called until it's supposed to be called. Calling the function
to prove it's callable is kind of like checking to see if a gun's safety
is on by pulling the trigger :-)

Okay, new scenario: we find a gun, and for some reason you are
willing to take my word for it that the safety is on, because
you intend to point it at your head and pull the trigger.

Which do you trust more: me looking at the safety and telling
you that it appears to be on, as I hand you the gun, or me
pulling the trigger and, if the gun doesn't fire, handing you
the gun? ...

The point is, that in the end, testing for callable only
tests for the *appearance*, correct though it may be in many
or most cases. No matter what, you can't prove that it can
be called until you try to call it. And in that case you
must still be prepared to handle the cases where the call fails,
or other situations.

What if I give you an object which appears to be callable, so
you stuff a reference somewhere in your constructor, because
after all "it's safe to call". Then, by the time you actually
try to call it, the object has morphed itself into something
without a __call__ method. The attempt to call it will fail.

Same logic as checking that a file exists before you actually
try to use it: no guarantee it will still exist later, so save
the wasted effort and just be ready for the exception that will
be thrown when it turns out not to exist.

There are times when what you are trying to do is the right
thing, maybe, probably, but it's rarely the case. If you are
sure, then callable() is what you need. Otherwise just catch
exceptions as appropriate.

-Peter

[Roy Smith]

"Terry Reedy" <tj*****@udel.edu> wrote:

but I don't actually want it called until it's supposed to be
called. Calling the function to prove it's callable is kind of like
checking to see if a gun's safety is on by pulling the trigger :-)

But it is the Python way. Someone recently asked how to test if one
can connect to a site without actually connecting and Alex M. gave
much the same answer I did. The frequent question "how can I tell if
I can read a file without actually reading it" gets the stock answer
'you can't, not for sure', just as iscallable is 'not for sure'.
I hear what you're saying, but it's still nice to be able to check ahead
of time. What you're saying is analagous to "Why bother checking the
safety because even if it's on now, by the time your finger slips and
touches the trigger, it might not be on any more".

Let's say I write this:

class eventThingie:
def __init__ (self, callback):
self.callback = callback

def go (self):
if magic stuff happens:
self.callback()

and then do:

myThingie = eventThingie (42)
myThingie.go()

When the magic stuff happens, I'll get a TypeError burried at the bottom
of a stack trace, and none of the lines in the stack trace will be where
my real error is. On the other hand, if I add "assert callable
(callback)" to my __init__() method, it'll be a lot easier to figure out
what went wrong because the stack trace will happen right when and where
the erroneous code is executed. It's just like trying to track down
pointer botches in C; by the time you get a segfault, you're nowhere
near the cause of the problem.

It's a tradeoff. By checking early, you give up a little flexibility
and theoretical purity, but what you get back is better testability.
Sorry, time-varying reality and the possibility of lies sometimes
bites

If by "time-varying reality" you mean the dynamic nature of the
language, that's an interesting problem. It is certainly possible in
theory that I could pass in an object which has no __call__() method, so
callable() would return False, but also guarantee that by the time the
object is actually called, I've managed to add a __call__() method to
the object. Theoretically possible, but diabolical, and not the kind of
thing I'm going to worry about.

[Roy Smith]

"Terry Reedy" <tj*****@udel.edu> wrote:

I disagree. The OP previously got the iscallable() answer, with the
caveat that True may be a lie, and I posted in that context. One
might still want to wrap the actual call in a try block. It is the
same for reading files or making socket connections. No matter what
pre-info one gathers, the acid test is to try to do it, and a careful
coder will prepare for possible failure.

There's a big difference between verifying that a passed parameter has
the properties it's supposed to have and trying to figure out if you can
read a file or open a socket.

The former catches a programming error. If I meant to pass fred and I
pass fred() by mistake, the problem is going to be there every time I
run the program until I fix the code.

The latter catches problems caused by external events. Files can appear
and disapper, or have their permissions change, at any time, and all
this is beyond the control (and knowledge) of my program. For things
like that, then yes, I agree that the way to find out if you can do
something is to try it and see what happens.

[Carl Banks]

Peter Hansen wrote:

Roy Smith wrote:

I want to test
the paramater for correctness in my constructor, but I don't actually
want it called until it's supposed to be called. Calling the function
to prove it's callable is kind of like checking to see if a gun's safety
is on by pulling the trigger :-)

Okay, new scenario: we find a gun, and for some reason you are
willing to take my word for it that the safety is on, because
you intend to point it at your head and pull the trigger.

Which do you trust more: me looking at the safety and telling
you that it appears to be on, as I hand you the gun, or me
pulling the trigger and, if the gun doesn't fire, handing you
the gun? ...

The point is, that in the end, testing for callable only
tests for the *appearance*, correct though it may be in many
or most cases. No matter what, you can't prove that it can
be called until you try to call it. And in that case you
must still be prepared to handle the cases where the call fails,
or other situations.

What if I give you an object which appears to be callable, so
you stuff a reference somewhere in your constructor, because
after all "it's safe to call". Then, by the time you actually
try to call it, the object has morphed itself into something
without a __call__ method. The attempt to call it will fail.

Same logic as checking that a file exists before you actually
try to use it: no guarantee it will still exist later, so save
the wasted effort and just be ready for the exception that will
be thrown when it turns out not to exist.

There are times when what you are trying to do is the right
thing, maybe, probably, but it's rarely the case. If you are
sure, then callable() is what you need. Otherwise just catch
exceptions as appropriate.

The OP said he wanted to use it inside an assertion. If he's using
assertions correctly, then this is one of those cases.

Assertions, used properly, test for conditions that are supposed to be
impossible. If something that was designed to be impossible occurs,
then there must be a bug somewhere. This is true whether an assertion
catches the impossible condition or not.

As a practical matter, using callable() is a good way to assert that a
value is callable. You see, callable() cannot return a false positive
unless there was already a bug in the program--it's not as if using
callable() here can introduce a bug where there was none previously.
(And, of course, callable() can't return a false negative.)

OTOH, using callable() inside an assertion will catch the vast
majority of non-callable values.
--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

[Terry Reedy]

"Roy Smith" <ro*@panix.com> wrote in message
news:ro***********************@reader2.panix.com.. .

I hear what you're saying,
?
but it's still nice to be able to check ahead of time.

Of course; I never said otherwise. Nor, that I remember, did I say to
not use callable(). I merely stated the reality that the ultimate
test for this particular property, in Python, is an actual call.

If I were writing the callback recipient purely for my own use, I
might decide to make no check and deal with the traceback should I
slip up and pass a non-callable. If I were writing a library routine
for the whole world to use, I might both test with callable() *and*
wrap the callback call.

A similar frequently asked question is "How can I check, before using
it, that a passed parameter is a number?" Seems simple, but depending
on the
definition of 'number', it may not be easily checkable in Python.
(See archives for more.)

Terry J. Reedy

[Terry Reedy]

"Roy Smith" <ro*@panix.com> wrote in message
news:ro***********************@reader2.panix.com.. .

There's a big difference between verifying that a passed parameter has the properties it's supposed to have and trying to figure out if you can read a file or open a socket.
Readability and connectability are also possible properties of passed
parameters. For your purpose of init-time checking, the relevant
property of properties is whether the property can be satifactorily
checked at init time or not.
The former catches a programming error. If I meant to pass fred and I pass fred() by mistake, the problem is going to be there every time I run the program until I fix the code.

And if you pass the name of an access prohibited file, that error will
also continue until fixed.

Alex Martelli has written several pages on 'look before you leap' (his
phrase) versus 'try and respond to failure' (not his). Look them up
for more discussion of this topic.

Terry J. Reedy

[Peter Hansen]

Terry Reedy wrote:

Alex Martelli has written several pages on 'look before you leap' (his
phrase) ...

That just put an image in my mind, of someone carefully inspecting
a chasm over which he intends to jump, measuring distance, making
sure that it's within his abilities.

He then backs up ten carefully measured paces, digs in his feet,
and surges forward, sprinting at top speed.

He flies towards the gap, his paces perfectly timed.

At the last moment, just as he launches himself into the air, the
ground under his foot crumbles away and he tumbles helplessly into
the void.

It might sound like a good idea, and even perhaps be a good idea,
to check things out ahead of time, but it's essential to understand
that, no matter what, you could overlook something or conditions
could change at the last instant just as you "do it for real".

Whether you use an assertion in __init__, or any other kind of
"look before you leap", just make sure to remember that you might
have overlooked some obscure way in which things could fail anyway.

Always handle exceptions. There's no robust alternative.

-Peter

[Gerrit Holl]

Gonçalo Rodrigues wrote:

On Sun, 05 Oct 2003 10:20:11 -0400, Roy Smith <ro*@panix.com> wrote:

"A.M. Kuchling" <am*@amk.ca> wrote:

There's a callable(param) built-in function, dating back to Python 1..2.

What does "appears callable" mean? Under what circumstances would
callable(foo) return True, yet foo() would fail?

An extreme and artificial example:
class FakeCallable(object): ... def __call__(self, *args, **kwargs):
... raise TypeError("My only purpose in life is to trick
the Python interpreter.")
... a = FakeCallable()
callable(a) True a()

Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "<interactive input>", line 3, in __call__
TypeError: My only purpose in life is to trick the Python interpreter.

Is there a difference between callable(a) and hasattr(a, '__call__')?

Gerrit.

--
121. If any one store corn in another man's house he shall pay him
storage at the rate of one gur for every five ka of corn per year.
-- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
http://people.nl.linux.org/~gerrit/
Kom in verzet tegen dit kabinet:
http://www.sp.nl/

[Duncan Booth]

Gerrit Holl <ge****@nl.linux.org> wrote in
news:ma**********************************@python.o rg:

Is there a difference between callable(a) and hasattr(a, '__call__')?

class C: pass callable(C), hasattr(C, '__call__')

(True, False)

A few other strange objects in the system show the same behaviour
(socket.socket for one), but new style classes and most builtin objects are
well behaved (i.e. they have the __call__ attribute if they are callable).

--
Duncan Booth du****@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?

[Gonçalo Rodrigues]

On Mon, 6 Oct 2003 11:52:12 +0200, Gerrit Holl <ge****@nl.linux.org>
wrote:

Gonçalo Rodrigues wrote:

On Sun, 05 Oct 2003 10:20:11 -0400, Roy Smith <ro*@panix.com> wrote:

> "A.M. Kuchling" <am*@amk.ca> wrote:
>> There's a callable(param) built-in function, dating back to Python 1.2. >What does "appears callable" mean? Under what circumstances would
>callable(foo) return True, yet foo() would fail?

An extreme and artificial example:

>>> class FakeCallable(object):

... def __call__(self, *args, **kwargs):
... raise TypeError("My only purpose in life is to trick
the Python interpreter.")
...

>>> a = FakeCallable()
>>> callable(a)

True

>>> a()

Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "<interactive input>", line 3, in __call__
TypeError: My only purpose in life is to trick the Python interpreter.

Is there a difference between callable(a) and hasattr(a, '__call__')?

Definitely yes. There are a few strange objects that are callable and
do not have a __call__. And you can make up your own:

class Wrapper(object): .... def __init__(self, obj):
.... super(Wrapper, self).__init__(obj)
.... self.__obj = obj
.... def __getattr__(self, attrib):
.... return getattr(self.__obj, attrib)
.... a = Wrapper(lambda *args, **kwargs: None)
a <__main__.Wrapper object at 0x010D4D50> hasattr(a, "__call__") True a() Traceback (most recent call last):
File "<interactive input>", line 1, in ?
TypeError: 'Wrapper' object is not callable

The gist is that the lookup for special methods does not use the usual
getattr machinery but just crawls the class's mro in search of it.

With my best regards,
G. Rodrigues

[Greg Ewing (using news.cis.dfn.de)]

Erik Max Francis wrote:

"Gonçalo Rodrigues" wrote:

Definitely yes. There are a few strange objects that are callable and
do not have a __call__.

I wouldn't call class objects all that strange :-).

It is strange behaviour, though, considering

class C: .... pass
.... type(C).__dict__.keys()

['__delattr__', '__setattr__', '__repr__', '__call__', '__str__',
'__getattribute__', '__new__']

so according to C's type, it *should* have a __call__ method.
I'm not sure exactly what's going on here.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Alex Martelli]

Greg Ewing (using news.cis.dfn.de) wrote:

Erik Max Francis wrote:

"Gonçalo Rodrigues" wrote:

Definitely yes. There are a few strange objects that are callable and
do not have a __call__.
I wouldn't call class objects all that strange :-).
_CLASSIC_ classes are very strange indeed, for backwards compat.

It is strange behaviour, though, considering
>>> class C: ... pass
... >>> type(C).__dict__.keys() ['__delattr__', '__setattr__', '__repr__', '__call__', '__str__',
'__getattribute__', '__new__']

so according to C's type, it *should* have a __call__ method.
I'm not sure exactly what's going on here.

BW compat -- type(C) (i.e <type 'classobj'>) is the weirdest
little beast in Pythonland.

Use newstyle classes only and keep your sanity...:

class C(object): pass ....
C.__call__ <method-wrapper object at 0x402ded8c>

Alex