bpo-39865: Don't lose exception context when __getattr__ is present

[ammaraskar]

When a class has a __getattr__ hook, it attempts to retrieve the attribute (e.g through a descriptor or the __dict__). If this initial attempt fails with AttributeError then a fallback is attempted on __getattr__. In turn, if the __getattr__ raises another AttributeError, then the original exception that caused the fallback is lost. This PR attempts to surface that information to avoid subtle bugs that might be caused by this.

The motivating example for this, as taken from the test is:

class A:
    @property
    def foo(self):
        a = 0
        a.accidental_attribute_error
        return 42
    def __getattr__(self, attr):
        if attr == 'foo':
            raise AttributeError("foo not supported in getattr")
        else:
            return 'fallback'

In this case, this class supports a.foo through a descriptor/property but has a bug in it. Previously attempting to access a.foo would lead to this traceback:

Traceback (most recent call last):
  File "lib\test\test_descr.py", line 2301, in test_property_fallback_exception
    a.foo
  File "lib\test\test_descr.py", line 2294, in __getattr__
    raise AttributeError("foo not supported in getattr")
AttributeError: foo not supported in getattr

This masks the original exception that caused the lookup to be delegated to __getattr__. However with the right cause set, the error message now looks like:

  File "lib\test\test_descr.py", line 2290, in foo
    a.accidental_attribute_error
AttributeError: 'int' object has no attribute 'accidental_attribute_error'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "lib\test\test_descr.py", line 2301, in test_property_fallback_exception
    a.foo
  File "lib\test\test_descr.py", line 2294, in __getattr__
    raise AttributeError("foo not supported in getattr")
AttributeError: foo not supported in getattr

which makes the real root cause of the bug a lot easier to diagnose. There's also external reason to believe that this might be a problem:

• https://stackoverflow.com/a/24260979/11365663
• https://github.com/davidhalter/jedi/blob/28c1ba6c1c757aa36ebc6a53d58115ba88e6c4f4/jedi/inference/utils.py#L52-L79

---

The code to set the cause could definitely use a helper in the PyErr_ namespace. It's pretty ugly as it stands now.

https://bugs.python.org/issue39865

[rhettinger]

Am marking this as rejected for the reasons listed in the bpo.

That said, I want to comment that this was really nice work. You did your homework and a good job on the PR. The only bone of contention is that the net cost/benefit suggests just leaving this alone.