21.3.0

The main reason for this comparatively timely release is that aiohttp 3.8's new behavior of starting new loops within aiohttp.web.run_app() led to breakage in apps that use structlog.stdlib.AsyncBoundLogger.

The one big new feature though is the support for much more powerful processor chains within structlog.stdlib.ProcessorFormatter. This took me way too long to get right, but I'm excited to share it with you.

This is also the first release without a setup.py. Invoking it was never tested and never supported, so now it's gone. Please use standard packaging tools like PyPA's build or flit directly if you want to package structlog yourself.

Backward-incompatible changes:

• structlog switched its packaging to flit. Users shouldn't notice a difference, but (re-)packagers might.

Deprecations:

none

Changes:

• structlog.dev.ConsoleRenderer now has sort_keys boolean parameter that allows to disable the sorting of keys on output. #358

• structlog.processors.TimeStamper now works well with FreezeGun even when it gets applied before the loggers are configured. #364

• structlog.stdlib.AsyncBoundLogger now determines the running loop when logging, not on instantiation. That has a minor performance impact, but makes it more robust when loops change (e.g. aiohttp.web.run_app()), or you want to use sync_bl before a loop has started.

• structlog.stdlib.ProcessorFormatter now has a processors argument that allows to define a processor chain to run over all log entries.

  Before running the chain, two additional keys are added to the event dictionary: _record and _from_structlog. With them it's possible to extract information from logging.LogRecords and differentiate between structlog and logging log entries while processing them.

  The old processor (singular) parameter is now deprecated, but no plans exist to remove it. #365