Feature or enhancement

Currently __cause__ and __context__ are expected to be exception objects (i.e. instances of BaseException). ¹ We don't always enforce this expectation, but we definitely do in some places.

Proposal

I'd like to allow them to be non-exception objects, as long as the objects look like exceptions. My own interest is that I be able to set either attribute to traceback.TracebackException objects specifically. However, I expect that supporting them would in practice mean supporting any object that matches the appropriate drop-in-replacement interface. [^2]

[^2] See gh-111917.

Note that I am not suggesting that we be able to use such drop-in-replacements anywhere the runtime expects exception objects. You couldn't start raising TracebackException objects nor catch them I don't have any motivating case for any of that. I'm only suggesting support in __cause__ and __context__.

drop-in-replacement for exception objects

The idea of drop-in-replacement (proxy or not) for an exception object isn't mine alone. The implication of the traceback.TracebackException docs is that it may be used as a representative proxy of an exception object. Furthermore, there has already been some consideration for treating TracebackException as a drop-in-replacement in actual technical situations, e.g. when pickling: #73652 (comment).

What would need to happen?

How are __cause__ and __context__ used (or might be used)?

• sys.excepthook()
• introspection
• (hypothetical?) raised directly after handling an exception
• ???

What would have to change?

• update TracebackException appropriately (it is used for the default sys.excepthook()²); the diff is actually relatively small
• ???

Other Notes

Prior discussion about supporting traceback.StackSummary where we currently support __traceback__: #74764 (comment)