Using __getattr__ and meeting expected behaviour for subclasses
<p>I am the author -- and currently almost definitely the sole user, if on multiple projects -- of <a href="https://github.com/Calama/kale/blob/master/kale.py" rel="nofollow">a simple database layer</a> (inspired by <a href="https://github.com/slacy/minimongo" rel="nofollow">minimongo</a>) for MongoDB called <code>kale</code>. My current use of <code>__getattr__</code> in the base class for models has led to some hard-to-track bugs.</p>

<p>The problem I've run into <a href="http://stackoverflow.com/questions/11116896/python-why-is-getattr-catching-attributeerrors">was articulated</a> concisely last June by David Halter on this site. The discussion is interesting, however no solutions were offered.</p>

<p>In short:</p>

<pre><code>&gt;&gt;&gt; class A(object):
...     @property
...     def a(self):
...         print "We're here -&gt; attribute lookup found 'a' in one of the usual places!"
...         raise AttributeError
...         return "a"
...     
...     def __getattr__(self, name):
...         print "We're here -&gt; attribute lookup has not found the attribute in the usual places!"
...         print('attr: ', name)
...         return "not a"
... 
&gt;&gt;&gt; print(A().a)
We're here -&gt; attribute lookup found 'a' in one of the usual places!
We're here -&gt; attribute lookup has not found the attribute in the usual places!
('attr: ', 'a')
not a
&gt;&gt;&gt;
</code></pre>

<p>Note that this contradictory behaviour is not what I would expect from reading <a href="http://docs.python.org/2/reference/datamodel.html#object.__getattr__" rel="nofollow">the official python documentation</a>:</p>

<blockquote>
  <p><strong><code>object.__getattr__(self, name)</code></strong></p>
  
  <p>Called when an attribute lookup has not found the attribute in the
  usual places (i.e. it is not an instance attribute nor is it found in
  the class tree for self). name is the attribute name.</p>
</blockquote>

<p>(It would be nice if they mentioned that <code>AttributeError</code> is the means by which "attribute lookup" knows if an attribute has been found in "the usual places" or not. The clarifying parenthetical seems to me at best incomplete.)</p>

<p>In practice, this has caused problems tracking down bugs caused by programming errors wherever an AttributeError is raised in a <code>@property</code> descriptor thing.</p>

<pre><code>&gt;&gt;&gt; class MessedAttrMesser(object):
...     things = {
...         'one': 0,
...         'two': 1,
...     }
...     
...     def __getattr__(self, attr):
...         try:
...             return self.things[attr]
...         except KeyError as e:
...             raise AttributeError(e)
...     
...     @property
...     def get_thing_three(self):
...         return self.three
... 
&gt;&gt;&gt; 
&gt;&gt;&gt; blah = MessedAttrMesser()
&gt;&gt;&gt; print(blah.one)
0
&gt;&gt;&gt; print(blah.two)
1
&gt;&gt;&gt; print(blah.get_thing_three)
Traceback (most recent call last):
  File "&lt;stdin&gt;", line 1, in &lt;module&gt;
  File "&lt;stdin&gt;", line 11, in __getattr__
AttributeError: 'get_thing_three'
&gt;&gt;&gt;
</code></pre>

<p>In this case it's pretty obvious what's going on by inspecting the class as a whole. However, if you rely on the message from the stack trace, <code>AttributeError: 'get_thing_three'</code>, it makes no sense, since, clearly, <code>get_thing_three</code> looks to be as valid an attribute as they come.</p>

<p>The purpose of <code>kale</code> is to provide a base class for building models. As such, the base model code is hidden away from the end programmer, and masking the cause of errors like this is not ideal.</p>

<p>The end programmer (<em>cough</em> me) may choose to use <code>@property</code> descriptors on their models,  and their code should work <em>and</em> fail in the ways they would expect.</p>

<p><strong>The Question</strong></p>

<p>How can I allow <code>AttributeError</code>s to propagate through my base class which has defined <code>__getattr__</code>?</p>
