From https://github.com/testing-cabal/testtools/issues/111 - any code that is data dependent can be hard to diagnose from a backtrace alone. Many unittest and server environments address this by doing custom tracebacks that include locals.

To address this in unittest, we need to add a similar capacity to traceback, and then use it from unittest (as we can't just depend on a module from PyPI in the stdlib).

See http://bugs.python.org/issue22936 for the unittest aspect of this.

Check out the cgitb stdlib module.

First cut implementation. I'm sure there is lots we can add, but this will make things nicer in and of itself.

Thanks for the pointer to cgitb, I've skimmed it and its definitely much more comprehensive. I'm not entirely sure about the best way to glue it and the new traceback API together; or even if thats needed.

updated with the latest 17911 patch basis.

And now updated to HEAD as 17911 has been committed.

Latest patch (issue-22936-4.patch) looks good to me!

New changeset 50741316dd3a by Robert Collins in branch 'default':
Issue #22936: Make it possible to show local variables in tracebacks.
https://hg.python.org/cpython/rev/50741316dd3a

In the patch you made some args kw-only.
Isn't that backward incompatible in case someone was passing them by position?

It's only the new APIs just introduced in issue #17911 that changed to kwonly arguments.

We missed that they should really be kwonly in the original review, but it become more obvious in this patch, as it added a second feature toggle to indicate whether or not to capture the locals.

You are right -- I didn't notice the versionadded in the docs.
Sorry for the noise.

No worries. BTW there is one more patch needed to close this issue - adding the feature to unittest. I'm working that up now.

And the unittest patch.

New changeset b4a26b28f5b3 by Robert Collins in branch 'default':
Issue #22936: Allow showing local variables in unittest errors.
https://hg.python.org/cpython/rev/b4a26b28f5b3

I just filed issue #23597 as a potential further follow-up to this, which would be to also add support for displaying local variables directly to the logging module.

However, that has some additional security implications, so I'm entirely convinced it's a good idea yet. See the new RFE for more details.

msg237320 "...so I'm *NOT* entirely convinced..."? :)

This itself is fixed.