Add context about the failed assert expression to AssertionError (make pytest magic easy)

[gpshead]

Background

The pytest package is widely used in the broader Python community in part because allows a more natural seeming way of writing test conditions in code via the use of the assert statement and a simple expression. Combined with some deep-juju magic that it runs where it does something like modifying the CPython internal implementation detail version specific AST or bytecode to extract meaningful contextual information from the assert frame and expression to generate an amazing amount of context in its failure error reports.

Desire

We should make doing this easy and well supported. Without any libraries wanting it to touch deep implementation and version specific details. This will make maintenance of those easier and improve the upgrade and testing path on new versions for the entire Python ecosystem.

Quoting a chat reply from Petr: _"""keep intermediate values while assert is evaluated, and find a way to map them to sub-expressions on failure. Ideally show that in native tracebacks like pytest does.

Only the success path needs low overhead. In a failed assertion, better debug info is worth a perf hit and creating reference cycles -- even outside tests."""_

This could perhaps become standard context we attach to AssertionError itself.

Pitch

The pytest implementation would get simpler when run in a Python version featuring this. The same kind of magic information display could then be applied anywhere an assert statement is used if desired. From unittest itself doing it, to logging.exception being able to include details, to the traceback module itself being allowed to turn on additional details in our default traceback display if desired... and similar within Jupyter / IPython notebooks (which may already have implementations of some of their own magic here? I haven't looked.)

Previous discussion

I originally brought this up on our Discord chat first as a vague question as it has been on my mind and needed to be let out. @encukou and @Fidget-Spinner and @sobolevn responded with ideas, including spawning work-in-progress #105724 to go ahead and add a low hanging fruit feature using our existing modern error location information feature.

If we need further discussion we should do that over on Discuss.p.o. But I wanted to make sure an issue was open to track the overall feature request and effort as a place to link to ideas and discussions if this spawns multiple pieces of work.

[boxed]

Just some other context: in hammett, I don't use the pytest rewriting method to get this information, but instead go back to the assert line on failure and reevaluate the subexpressions. The reason I do this is that hammett is made specifically to explore how fast a pytest-like test runner can be and assertion rewriting is fairly slow. The problem with the reevaluation method is that it doesn't work in the general case, because the same expression run again can produce different results, for example if there is a generator involved.

So in summary: I love this proposal :P

[RonnyPfannschmidt]

I do have a pep proposal in my own backlog but haven't been able to commit Time too it for various personal reasons