Add 'structlog.stdlib.render_to_log_args_and_kwargs' processor

[denis-savran]

Summary

Added structlog.stdlib.render_to_log_args_and_kwargs processor.

Same as structlog.stdlib.render_to_log_kwargs, but also allows to pass positional arguments to logging.
With it, you do not need to add structlog.stdlib.PositionalArgumentsFormatter processor to format positional arguments from structlog loggers.

Usage example:

structlog.configure(
    processors=[structlog.stdlib.render_to_log_args_and_kwargs],
    wrapper_class=structlog.stdlib.BoundLogger,
    logger_factory=structlog.stdlib.LoggerFactory(),
    cache_logger_on_first_use=True,
)

logging_config = {
    ...
    "formatters": {
        "default": {
            "()": structlog.stdlib.ProcessorFormatter,
            "processors": [
                ...
                structlog.stdlib.ProcessorFormatter.remove_processors_meta,
                structlog.processors.JSONRenderer(),
            ],
        },
        ...
    },
    ...
}
logging.config.dictConfig(logging_config)

logger = structlog.stdlib.get_logger(__name__)
...
    logger.info("message: a = %s, b = %d", "foo", 123)
# Outputs:
#  {"event": "message: a = foo, b = 123"}

With this configuration we can use the same processors for both structlog and logging 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 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]

hey thanks for hanging in there; it looks like a good change but the PR is a big boi, so I'll have to find time/focus for reviewing first. I will do that before the next release tho.

[denis-savran]

Hello, thank you.

[hynek]

This is great, thanks!