5

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.

Pace
  • 571
  • 6
  • 17
  • Have you seen [Python Forgiveness vs. Permission and Duck Typing](http://programmers.stackexchange.com/q/175655) at all? – Martijn Pieters Nov 29 '12 at 14:25
  • 1
    And note that in daily Python work you usually do *not* have to deal with duck typing all that often. – Martijn Pieters Nov 29 '12 at 14:26
  • Some weeks ago I asked this question: http://programmers.stackexchange.com/questions/161798/is-it-easier-to-write-robust-code-in-compiled-strictly-typed-languages There I asked whether in loosely typed languages you had to work extra doing type checks, and I was bombarded by people saying you hadn't and the question got closed. Now I see you have. In strictly typed languages the wrong type assignment simply couldn't compile. No "quacking" necessary. – Tulains Córdova Nov 29 '12 at 15:58
  • 1
    @user1598390: Let's keep your discussion to the question you already posted. – Martijn Pieters Nov 29 '12 at 16:03
  • @MartijnPieters Nope, I hadn't seen that question. Won't let me close it at this point although that's probably for the best as pilmuncher's answer is exactly what I was looking for. – Pace Nov 30 '12 at 03:10

2 Answers2

6

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

Community
  • 1
pillmuncher
  • 853
  • 1
  • 6
  • 7
  • If performance really the only reason? I think that's a pretty bad reason for turning two lines into five. –  Nov 29 '12 at 19:00
  • @delnan: I couldn't find any other reason, except that it seems to be the canonical way, or was, per [the Python Cookbook](http://shop.oreilly.com/product/9780596007973.do), 2nd ed., IIRC. But even its editor, Alex Martelli, [now prefers `hasattr()`](http://stackoverflow.com/a/903138/395321). – pillmuncher Nov 29 '12 at 19:39
  • That's what I get for not doing my research. Your approach solves both my concerns with the try/except. – Pace Nov 30 '12 at 03:13
  • As for your last point. I am essentially constructing a dependency injection container. If the components have an init method I call it, if they don't, I don't. I would be extremely interested in another approach which is cleaner. – Pace Nov 30 '12 at 03:22
0

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.

stonemetal
  • 3,371
  • 16
  • 17