This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Preserve AttributeError exception context in __getattr__
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Arusekk, ammar2, pasenor
Priority: normal Keywords: patch

Created on 2020-05-05 14:32 by Arusekk, last changed 2022-04-11 14:59 by admin.

Files
File name Uploaded Description Edit
typeobject.patch Arusekk, 2020-05-05 14:32 The simpler patch
robust.patch Arusekk, 2020-05-05 14:36 The robust patch
Messages (2)
msg368152 - (view) Author: (Arusekk) * Date: 2020-05-05 14:32
This is another attempt at issue 39865, but with a different attitude. Please see that issue for some extra motivation for this change.

My suggestion is to change getattr logic, which now is (in this case):

def getattr(obj, attr):
    try:
        return normal_getattr(obj, attr)
    except AttributeError:
        pass
    return obj.__getattr__(attr)

to be more like:

def getattr(obj, attr):
    try:
        return normal_getattr(obj, attr)
    except AttributeError:
        return obj.__getattr__(attr)

A __getattr__ function would then be able to know the exception context
(through sys.exc_info()) and to have the context automatically attached to all the exceptions raised (still respecting raise ... from None).

This particular issue only lies in Objects/typeobject.c, but is probably valid for other uses of PyErr_Clear() in the interpreter.
I checked some using a simple shell pipeline:

$ grep -r -A5 PyErr_ExceptionMatches |grep -C5 PyErr_Clear

And found some interesting examples of what be worth looking into:
Python/sysmodule.c:708
Parser/tokenizer.c:1110
Objects/memoryobject.c:fix_error_int

I prepared two patches for this (please forgive if I violated code style somewhere, I am not saying that they are a final version ready to be merged): a simple one, addressing just this very issue, and a robust one, allowing other places (e.g. from the list above) to reuse it.
msg368154 - (view) Author: (Arusekk) * Date: 2020-05-05 14:36
Feel free to reuse the patches if you have better ideas
History
Date User Action Args
2022-04-11 14:59:30adminsetgithub: 84699
2020-05-05 14:36:34Arusekksetfiles: + robust.patch

messages: + msg368154
2020-05-05 14:32:40Arusekkcreate