I’ve seen countless times the following approach suggested for “taking in a collection of objects and doing X if X is a Y and ignoring the object otherwise”
def quackAllDucks(ducks):
for duck in ducks:
try:
duck.quack("QUACK")
except AttributeError:
#Not a duck, can't quack, don't worry about it
pass
The alternative implementation below always gets flak for the performance hit caused by type checking
def quackAllDucks(ducks):
for duck in ducks:
if hasattr(duck,"quack"):
duck.quack("QUACK")
However, it seems to me that in 99% of scenarios you would want to use the second solution because of the following:
- If the user gets the parameters wrong then they will not be treated like a duck and there will be no indication. A lot of time will be wasted debugging why there is no quacking going on until the user finally realizes his silly mistake. The second solution would throw a stack trace as soon the user tried to quack.
- If the user has any bugs in their quack() method which cause an AttributeError then those bugs will be silently swallowed. Once again time will be wasted digging for the bug when the second solution would simply give a stack trace showing the immediate issue.
In fact, it seems to me that the only time you would ever want to use the first method is when:
- The block of code in question is in an extremely performance critical section of your application. Following the principal of “avoid premature optimization” you would only realize this of course, after you had implemented the safer approach and found it to be a bottleneck.
- There are many types of quacking objects out there and you are only interested in quacking objects that quack with a very specific set of arguments (this seems to be a very rare case to me).
Given this, why is it that so many people prefer the first approach over the second approach? What is it that I am missing?
Also, I realize there are other solutions (such as using abcs) but these are the two solutions I seem to see most often for the basic case.
5
The reason you should use the first version is performance. Raising an exception is most often cheaper than calling a method or a function.
The first argument you present for using the second version is not quite valid, since using if hasattr(duck, 'quack'): also would silently prevent the call to duck.quack() and no exception would be raised.
Your second argument only applies because your implementation is not correct. You should instead do it like so:
def quackAllDucks(ducks):
for duck in ducks:
try:
duck.quack
except AttributeError:
#Not a duck, can't quack, don't worry about it
continue
duck.quack("QUACK")
Then any exception raised inside of duck.quack() would be propagated to the caller of quackAllDucks().
[EDIT]
delnan raised a good question in his comment below. It lead me to further investigate, and the recomended way now seems to be to use hasattr().
But the best solution is probably to design your program so that it doesn’t depend on such tests. As Steve Oualline said, “If we don’t write code like this, then we don’t have to worry about such questions”.
4
The problem is there is no difference between the two. duck.quack() calls __ getattr__ to look up the quack attribute then attempts to invoke what comes back. hasattr makes the same __ getattr__ function call then returns false if it throws an exception. So basically the second version is identical to the first version except you have a double look up of the quack attribute.
1