Much like ImportError now has 'name' and 'path', AttributeError should get an 'attr' attribute that can only be set through a keyword argument or after creating an instance. That would make the common ``try/except AttributeError`` uses much more robust by not accidentally swallowing an AttributeError that has nothing to do with the attribute in question::

 try:
   cls.meth()
 except AttributeError as exc:
   if exc.attr != 'meth':
     raise

+1 on this, but it's worth noting that that fix is not 100% correct (though it's obviously better than most existing equivilants), it's potentially wrong with custom __getattr__, __getattribute__, descriptors.

Such custom implementations should be updated to support this wonderful new attr. :)

What Benjamin said.

Adding something like this is mostly about a nicer constructor (``AttributeError(attr='meth')``) and automatically creating the message for the exception (although that would require another argument like 'object' or something to be able to do e.g. "'dict' object has no attribute 'asdfdsff'" or "type object 'dict' has no attribute 'asdfdsf'").

And standardizing on an attribute name, of course. =)

I've been working on this at the EuroPython sprint today and it seems the change requires editing >20 files that call PyExc_AttributeError. This means it would be quite a big and dangerous change, so for now I just attach the optional argument addition - without it actually being used by the rest of the codebase.

What is your oppinion on it?

Even porting to the new wonderful 'attr' field is not going to make the code correct... (the exception could be bubbling up from code down ten frames about a different unrelated attribute that happens to have the same name in a different object). BTW cpython has a lot of those "except AttributeError" fragments coded in C with PyErr_ExceptionMatches.

Dražen: didn't do a deep review, but a cursory look suggests the patch is fine.

As for having to change a ton of files to start using the attribute, that's part of the effect of changing something as basic as an exception. If you would rather break it up into separate patches that's fine. But I would caution you from doing more than this patch as I have gotten some push back from other core devs on my proposed new attributes on exceptions so I don't want you spending your time on something that might get sunk (although if you are enjoying it then go for it since if it gets accepted this work will be needed).

Also please sign the contributor agreement form (http://python.org/psf/contrib/contrib-form/) so that we can actually use your code.

Andrea: While the attribute might coincidentally name an attribute that is the same as some other attribute which is not the actual trigger, the traceback on the exception provides the proper context to know what attribute in what code did the actual triggering. The point is that the exception can be considered better than nothing and is still an improvement over not having the information at all.

OK, thanks for the feedback. I signed the CLA.

I'll then wait with the remaining work, until a final decision has been made. We have a rough idea of how it could be implemented if it comes to this - adding a wrapper function in Python/errors.c:

    PyErr_SetAttributeError(PyObject *attr, const char *format, ...)

that would replace all the PyErr_SetObject, PyErr_SetString and PyErr_Format calls (in around 50 files), create the kwargs object, format the message (if provided) and call PyErr_SetObject or PyErr_SetFormat.

I put the last patch as a commit in the attr bookmark on BitBucket (took me quite some time to figure out that's the alternative to git branches), so that subsequent changes go more easily.

In issue22716 proposed to add a reference to the object missing an attribute.

I closed #22716 in favor of this, since I think both should be tackled together.

yeah, exactly: my idea was to add a reference to the original object (AttributeError.target). together with this bug, that would be the AttributeError part of PEP 473, which i really like!

I'd like to ping this channel.

I post a question on https://groups.google.com/forum/#!topic/comp.lang.python/y8yDAAJJ9Sc to ask if it is possible to directly get the attribute from AttributeError, which leads me here.

> try:
>   cls.meth()
> except AttributeError as exc:
>   if exc.attr != 'meth':
>     raise

What if cls.__getattr__('meth') calls a completly unrelated function which also raises AttributeError(attr='meth') but on a different object? I would also expect an "obj" attribute, a reference to the object which doesn't have attribute.

But AttributeError can be raised manually without setting attr and/or obj attribute. So the best test would look to something like:

if exc.obj is cls and exc.attr is not None and exc.attr != 'meth':
    raise

The test is much more complex than expected :-/ Maybe it's simpler to split the code to first get the bounded method?

try:
   meth = cls.meth
except AttributeError:
   ...
meth()

Or check first if cls has the attribute 'meth' with hasattr(cls, 'meth')?

--

About attr/obj attribute not set, an alternative is to add a new BetterAttributeError(obj, attr) exception which requires obj and attr to be set, it inherits from AttributeError.

class BetterAttributeError(AttributeError):
   def __init__(self, obj, attr):
       super().__init__('%r has no attribute %r' % (obj, attr)
       self.obj = obj
       self.attr = attr

It would allow a smoother transition from "legacy" AttributeError to the new BetterAttributeError.

The major issue with keeping a strong reference to the object is that Python 3 introduced Exception.__traceback__ which can create a reference cycle if an exception is stored in a local variable somewhere in the traceback. It's a major pain point in asyncio. In asyncio, the problem is more likely since exceptions are stored in Future objects to be used later.

The concerns mentioned by haypo seems to have existed in PEP473.