Check a dict passed to ProcessorFormatter actually came from structlog. #188
Conversation
Add the failing test case for issue #187.
ProcessorFormatter assumes certain attributes are attached by wrap_for_formatter but originally only tested if it was receiving a dictionary as the log message. This breaks if any libraries you use happen to pass dictionaries as log messages expecting them to print using default string formatting. Fortunately since the behavior of the LogRecord is different between the two paths, we can resolve this by testing for the relevent attrs before choosing. Fixes #187.
| if isinstance(record.msg, dict): | ||
| if ( | ||
| isinstance(record.msg, dict) | ||
| and hasattr(record, "_logger") |
There was a problem hiding this comment.
Please meet: https://hynek.me/articles/hasattr/ :)
If we pile on checks and assume that dicts are predominant, why don't we invert the whole thing and make it an try:…except (KeyError, AttributeError)? I reckon that’s considered more pythonic too.
There was a problem hiding this comment.
I would argue when you have the ProcessorLogger in the mix, dicts and strs aren't predominant one way or the other, so a try...except seems unnecessarily slow.
I wonder if instead the wrapper should convert LogRecord into WrappedLogRecord and just do a type-check since ultimately what we're looking for is a different object type.
There was a problem hiding this comment.
try...except seems unnecessarily slow.
Hm, do you really think it's slower than multiple checks on each record? I think I'd like to see a benchmark on that since this is is hot code. If you have some spare it would be great if you could compare it using https://pypi.org/project/perf/ . I only care about modern Python versions FWIW.
I wonder if instead the wrapper should convert LogRecord into WrappedLogRecord and just do a type-check since ultimately what we're looking for is a different object type.
That sound clean, but really slow? 🤔
Sorry I'm being so anal about performance here but I take great pride that structlog isn't a handbrake like logging and I'd like it to stay that way. 😇
There was a problem hiding this comment.
No I agree about keeping it quick. I'll setup some tests.
There was a problem hiding this comment.
Awesome thank you and sorry for the delay. My original plan was to run them myself but just didn't get around to it.
|
bump? :) |
ProcessorFormatter assumes certain attributes are attached by wrap_for_formatter
but originally only tested if it was receiving a dictionary as the log message.
This breaks if any libraries you use happen to pass dictionaries as log messages
expecting them to print using default string formatting.
Fortunately since the behavior of the LogRecord is different between the two
paths, we can resolve this by testing for the relevent attrs before choosing.
Fixes #187