To avoid this, I think property and cached_property need to wrap the function call in another try-except block and re-raise a different error code than AttributeError. e.g.

try:
    val = self.func(instance)
except Exception as E:
    raise RuntimeError("Property evaluation failed!") from E

instead of the plain

Not sure if this is a "bug". The doc clearly states that __getattr__ will be called when the default attribute access fails with an AttributeError. Yes, the AttributeError is raised in your code, but it's still an AttributeError and the correct behavior is to call __getattr__ -> which raised the error you saw.

@gaogaotiantian The problem is that the error message doesn't show in the traceback, which makes it difficult to debug. I wrote this after spending quite some time debugging, because I thought there was a problem with my __getattr__, when the real error occurred in the computation of the property. Tracebacks should always go back to the original source of the error, no?

The AttributeError raised in your property is handled so it won't show in traceback. Think of it as:

try:
    obj.prop()
except AttributeError:
    Foo._getattr__(obj, "prop")

I believe the original design for this is for a "non-exist" attribute, not an AttributeError raised when evaluating the attribute. However, I think this is a well-documented expected behavior.

Your proposal is a breaking change, which would affect code that actually taking advantage of this behavior. For example, I might want property methods that make the attribute "appear to be non-existent" so that it could be handled as a missing attribute.

class A:
    @property
    def data(self):
        if <condition>:
            return ...
        else:
            raise AttributeError()

This is a long-existing and fully documented behavior from before Python 3.5.

Do not raise AttributeError then.

@sunmy2019

Do not raise AttributeError then.

In my case, there was an actual bug in my code, I wasn't intentionally raising an AttributeError during the evaluation of the property (I accidentally used .loc on a pandas.Index object). My point is: if the attribute lookup fails, the traceback should include the error message!

But even when it is intentional, like in the example @gaogaotiantian gave:

class A:
    @property
    def data(self):
        if <condition>:
            return ...
        else:
            raise AttributeError("Failed to load property due to <condition>")

Wouldn't it make sense to include the message "Failed to load property due to <condition>" if __getattr__ fails? I would expect the following behavior:

• If the default default attribute access fails with an AttributeError(msg), then try __getattr__.
• If __getattr__ fails as well, include msg in the traceback.
• Instead, currently we only get the error message from __getattr__!

I believe both you and @gaogaotiantian have misunderstood the point of this issue. The issue is not about how Python's mechanism for looking up attributes works, the issue is that if that mechanism fails, not all relevant error messages are included in the traceback!

Here is an updated MWE to more clearly demonstrate the issue:

import pandas as pd

class MWE:
    @property
    def foo(self):
        s = pd.Index([1,2,3])
        return s.iloc[0]   # actual bug! pd.Index has no .iloc attribute

MWE().foo  # AttributeError: 'Index' object has no attribute 'iloc'
# without `__getattr__`  implemented we get the right error message!


class MWE_with_getattr:
    def __getattr__(self, key):
        if key == "dummy":
            return "xyz"
        raise AttributeError(f"{self.__class__.__name__} has no attribute {key}!")

    @property
    def foo(self):
        s = pd.Index([1,2,3])
        return s.iloc[0]   # actual bug! pd.Index has no .iloc attribute


MWE_with_getattr().foo  # AttributeError: MWE_with_getattr has no attribute foo!
# Traceback never mentions "AttributeError: 'Index' object has no attribute 'iloc'"
# Implementing `__getattr__` gobbles up the error message!

• If __getattr__ fails as well

if it succeeded, then there is no way to indicate this failure of property access.

• If __getattr__ fails as well

if it succeeded, then there is no way to indicate this failure of property access.

That's outside the scope of this issue.

@randolf-scholz , first of all, we should all agree that this is not a bug report anymore, this is a feature request now. The code behaves as expected and documented, what you want is something more - a better traceback message.

I agree that in your case, being able to know where the attribute error originated would be helpful. The original improvement of yours (reraising as a different exception) was a breaking change (the code I gave would behave differently) so I don't think that would happen.

Is it possible to make __getattr__ track the original AttributeError and raise from it when there's an exception happening in __getattr__? I believe theoretically yes. However, how would you treat the much more common use cases - the normal attribute missing and AttributeError in __getattr__? You would have two redundent tracebacks - the original AttributeError would not contain any useful information.

I don't think it's worth it to complicate a more common use case, just to make a rare one better.

In this specific case, I think the right path is:

    @property
    def foo(self):
        try:
            s = pd.Index([1,2,3])
            return s.iloc[0]   # actual bug! pd.Index has no .iloc attribute
        except AttributeError as exc:
            raise RuntimeError() from exc

Or, write your own wrapper for properties.

You may argue that the user would have to know that the code in the method could potentially raise AttributeError to be able to do this, that's right and that's what they need to consider when they use __getattr__ - it's documented clearly that the method will be called when there's an AttributeError, and the user is responsible to deal with the unexpected AttributeError.

@gaogaotiantian

However, how would you treat the much more common use cases - the normal attribute missing and AttributeError in getattr? You would have two redundent tracebacks - the original AttributeError would not contain any useful information.

I don't see any problem in that, and in fact, it can be a very useful thing as your own example demonstrates:

class A:
    def __getattr__(self, key):
        try:
            attr = self._fallback(key)
        except Exception as E:
            raise AttributeError(f"{self} has no attribute {key}!") from E
        else:
            return attr

    @property
    def data(self):
        if <condition>:
            return ...
        else:
            raise AttributeError("Failed to load property due to <condition>")

With current behavior, if self._fallback(key) fails (for example with NotImplementedError), one only gets the message "object has no attribute data!", without any information about why the original <condition> failed. I'd wager that most of the time, this is useful info to have.

one only gets the message "object has no attribute data!"

This is in the doc.

object.__getattr__ should either return the (computed) attribute value or raise an AttributeError exception.

I think AttributeError is like a bridge for __getattr__ and normal attributes.

@sunmy2019

This is in the doc.

I don't see it explicitly described there. When I read the

My intuitive expectation would be that the attribute-lookup roughly works as:

class object:
    def __getattribute__(self, key):
        try:
            attr = self._default_attribute_lookup(key)
        except AttributeError as E:
            try:  # alternative lookup via __getattr__
                attr = self.__getattr__(key)
            except Exception as F:
                raise F from E   # re-raise if __getattr__ fails as well
            else:
                return attr
        else:
            return attr

But instead, the original error gets swallowed if __getattr__ fails as well.

class object:
    def __getattribute__(self, key):
        try:
            attr = self._default_attribute_lookup(key)
        except AttributeError as E:
            # if __getattr__ fails, we are left in the dark as to why default lookup failed.
            return self.__getattr__(key)  
        else:
            return attr

I can imagine that possibly the nested try-except block was avoided for performance reasons. But since we have "Zero cost" exception handling (#84403) now, that shouldn't be an issue anymore.

I think this is a valid and reasonable feature request. There may be reasons not to do it that would become clear in attempting to implement it, but I don't see a priori reasons to dismiss the feature.

The only real objection to the chaining that has been raised so far is this one:

how would you treat the much more common use cases - the normal attribute missing and AttributeError in getattr? You would have two redundent tracebacks - the original AttributeError would not contain any useful information.

But I don't think this is a strong objection. In this case, the newly-chained exception would accurately reflect the situation: a normal attribute access failed, __getattr__ was called, and it also failed with an exception. The traceback would be longer than it is now, but it wouldn't be misleading or confusing. The exception you get currently would still be featured at the "bottom" of the traceback. And in more complex cases, critical debugging information wouldn't be totally hidden.

I agree with @carljm. This isn't a bug, and the the original suggestion of wrapping the AttributeError with a RuntimeError would have broken a lot of code. But the suggestion of chaining the exception is much stronger, and could be a pretty useful feature in some situations.

Sure, we can try to build a prototype and see if breaks anything unexpected.

Just encountered this again, after some very painful debugging I found https://stackoverflow.com/questions/36575068 and remembered that I had this issue before.

user2483412 Provided a good workaround:

def __getattr__(self, name):
    if name == 'abc':
        return 'abc'
    return self.__getattribute__(name)

instead of

def __getattr__(self, name):
    if name == 'abc':
        return 'abc'
    raise AttributeError

I still think that the re-raising should, because this is incredibly frustrating to debug. One could even add a note to consider this implementation.

Just encountered this again, after some very painful debugging I found https://stackoverflow.com/questions/36575068 and remembered that I had this issue before.

user2483412 Provided a good workaround:

def __getattr__(self, name):
    if name == 'abc':
        return 'abc'
    return self.__getattribute__(name)

I would be wary of this approach, as it basically means the attribute access flow is __getattribute__ -> __getattr__ -> __getattribute__ again. It can make things even more unclear from a development perspective and have unexpected side-effects. Your property getter will now run twice, so any side-effects introduced the first time running the getter may impact how it runs the second time. I've recently discovered a tricky bug with DRF due to this exact type of error handling.

In the bug, during the first attribute access, the property would check if an instance attribute is already set, and if it was, it would be immediately returned. Otherwise, it would run a function to create the value for that attribute. If that function raised an exception, the instance attribute would be set to an empty value and the error would be re-raised. Below is a minimal example:

class Request:

    _data = None

    @property
    def data(self):
        if self._data is None:
            self.load_data()

        return self._data

    def load_data(self):
        try:
            self._data = do_something()
        except:
            self._data = {}
            raise

Now with the flow mentioned above, if an AttributeError was raised, the property getter would run twice (via the two calls to __getattribute__). On the second time, the property getter would now have a valid (but empty and incorrect) value for that attribute to return. This ended up suppressing a bug with my code, which was using DRF, and it made it seem like everything was working as expected when it wasn't.