Improve dict traceback

[sscherfke]

Summary

Restore feature parity between Rich's traceback extractor:

• When displaying locals, call repr() on strings, too.
• Add locals_max_length config option
• Add locals_hide_sunder config option
• Add locals_hide_dunder config option
• Add suppress config option

Pull Request Check List

• Do not open pull requests from your main branch – use a separate branch!
  • There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
  • This is not a pre-requisite for your your pull request to be accepted, but you have been warned.
• Added tests for changed code.
  • The CI fails with less than 100% coverage.
• New APIs are added to our typing tests in api.py.
• Updated documentation for changed code.
  • New functions/classes have to be added to docs/api.rst by hand.
  • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
    • The next version is the second number in the current release + 1. The first number represents the current year. So if the current version on PyPI is 23.1.0, the next version is gonna be 23.2.0. If the next version is the first in the new year, it'll be 24.1.0.
• Documentation in .rst and .md files is written using semantic newlines.
• Changes (and possible deprecations) are documented in the changelog.
• Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.

[hynek]

2 questions before I get around to looking at it closely:

• Why are you inverting our asserts? We do expected == result and it happens that one forgets it in new code, but why are there changes to existing one?
• Is this related at all to Question about configuring show_locals for json output #626 (which used to claim that show_locals=False does nothing)

[sscherfke]

wb, @hynek :)

Why are you inverting our asserts? We do expected == result and it happens that one forgets it in new code, but why are there changes to existing one?

I noticed that result == expected and expected == result were mixed in that file so I unified it to the "official" result == expected version. I can change it back though if you want.

Is this related at all to #626 (which used to claim that show_locals=False does nothing)

I was not aware of this question but I will take a look at it. The changes come from requirements at work.

[hynek]

wb, @hynek :)

thanks 😵‍💫

Why are you inverting our asserts? We do expected == result and it happens that one forgets it in new code, but why are there changes to existing one?

I noticed that result == expected and expected == result were mixed in that file so I unified it to the "official" result == expected version. I can change it back though if you want.

Please do; we've sufficiently departed anyways.

Is this related at all to #626 (which used to claim that show_locals=False does nothing)

I was not aware of this question but I will take a look at it. The changes come from requirements at work.

I'm not sure it's legit, since he edited it out, but please have a look.

[sscherfke]

Updated the PR and answered the linked question. :-)

[hynek]

I didn't look super close at the code since I assume it's coming from Rich and well-tested.

I expect people to complain about the always-on Rich formatting tho, so I think it should be an option?

[hynek]

thanks!

not gonna do a deep review and trust Will here :)