Long story short: it is accessed due to the callable suffix check (Issue 449227), and this check is less than optimal, meaning the attribute gets accessed up to four times per Tab press.

In 3.6, there are only two calls, one for the hasattr() call, and one for the getattr() call:

Foo.bar called
  File "/home/proj/python/cpython/Lib/rlcompleter.py", line 85, in complete
    self.matches = self.attr_matches(text)
  File "/home/proj/python/cpython/Lib/rlcompleter.py", line 164, in attr_matches
    hasattr(thisobject, word)):
  File "<stdin>", line 3, in bar
Foo.bar called
  File "/home/proj/python/cpython/Lib/rlcompleter.py", line 85, in complete
    self.matches = self.attr_matches(text)
  File "/home/proj/python/cpython/Lib/rlcompleter.py", line 165, in attr_matches
    val = getattr(thisobject, word)
  File "<stdin>", line 3, in bar

Before revision 4dbb315fe667 (Issue 25011), “words” was a list rather than a set. It gets two “bar” entries, one from dir(f) and one from dir(f.__class__). Maybe it is worth backporting set(), I dunno.

The hasattr() call was added in r65168 (Issue 3396) as a look-before-you-leap check to avoid the completer from dying from getattr() exceptions. IMO in this case it is better to “ask for forgiveness” by catching Exception from getattr(). This would be more robust to quirky and buggy attributes anyway.

Finally (or really, initially), getattr() was added in r64664 (Issue 449227). I think even if getattr() fails, the attribute name could still be output, just not with the callable suffix (which I partly disagree with anyway). It would have been like that previously. But I guess this is debatable, and a separate issue.