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 hassort_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 usesync_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 fromlogging.LogRecord
s and differentiate betweenstructlog
andlogging
log entries while processing them.The old processor (singular) parameter is now deprecated, but no plans exist to remove it. #365