Make stdlib.BoundLogger.exception call Logger.exception

[bcdickinson]

Summary

Closes #571

It does these things:

• Makes the structlog.stdlib.BoundLogger.exception proxy to the wrapper Logger's exception method, instead of error. This is useful for the niche use case of Handler classes that need to deal with both structlog and non-structlog records and prevents such handlers having to reconstruct record.exc_info for themselves or rely on structlog processors to do it
• Makes the handling of ProcessorFormatter's keep_exc_info and keep_stack_info args consistent for log records originating from both structlog and non-structlog loggers.

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.

[bcdickinson]

@pahrohfit Now the tests are green on the main branch again I've rebased this. I'd be really grateful for a review and any feedback you may have!

[hynek]

This looks mostly good (although, I once again, regret ever adding stdlib support to structlog as I'm trying to massage away a migraine), but it seems to me that you haven't added a test that ensures that your use-case doesn't break in the future. Would that be feasible?

[bcdickinson]

... you haven't added a test that ensures that your use-case doesn't break in the future.

Excellent point 🤦

I've added a regression test in my latest commit and rebased this again now. Thanks for looking at this, I'm sorry the stdlib integration causes you pain 😅 I'm extremely grateful for it, it's been so useful to me over the last few months!

[hynek]

... you haven't added a test that ensures that your use-case doesn't break in the future.

Excellent point 🤦

I've added a regression test in my latest commit and rebased this again now. Thanks for looking at this, I'm sorry the stdlib integration causes you pain 😅 I'm extremely grateful for it, it's been so useful to me over the last few months!

Thank you for the kind words – structlog usually only comes up when people complain about it. 😅

I have added a changelog entry – it would be nice if you could check it for accuracy, because , again, I'm trying to forget as much about this as possible. ;)

[bcdickinson]

Changelog entry LGTM, thanks for merging!