Closed umesh-timalsina closed 1 year ago
LogRecord.msg is defined to be:
msg (str) – The event description message, which can be a %-format string with placeholders for variable data.
So I think passing an int here would be a bug. But it does say it should support custom Message types, as long as they have a __str__
method that returns an appropriate format string, so we should do the same and getMessage seems like the right call, thanks!
Did I just happen to also run in to this the same week, or is it a regression?
I don't think this file has been touched in a pretty long time, so coincidence seems likely.
What pyzmq version?
25.0.0
What libzmq version?
4.3.4
Python version (and how it was installed)
Python 3.10.8 | packaged by conda-forge | (main, Nov 22 2022, 08:26:04) [GCC 10.4.0] on linux
OS
Ubuntu 22.04
What happened?
Apparently, the
emit
function in pyzmq's PubHandler doesn't take into account the possibility of typecasting when applying thesplit
function for a LogRecord's msg attribute in python. This causes a lot of issues when the log handler is used in conjunction with the logger already in existence. A possible resolution might be to usegetMessage
instead which does the type casting.https://github.com/zeromq/pyzmq/blob/9b767422dd8b32c29496d5fe1858b4e325fb42d2/zmq/log/handlers.py#L132-L157
Code to reproduce bug
Traceback, if applicable
More info
No response