Closed vikramsubramanian closed 2 weeks ago
Thanks for pointing this out. :+1:
I'll investigate it and fix it before official 3.11 release.
Fixed on master
. The 3.11 version was also added to CI tests.
The reported error due to patched_stat()
was an easy fix (missing arguments).
However, the 3.11 version also "breaks" the InterceptHandler
implementation due to
Users must update their existing InterceptHandler
while upgrading to 3.11 (replace logging.currentframe()
with sys._getframe()
).
can you please create a release that has this fix? We're currently rebuilding all Python packages against 3.11 on Arch Linux and I am now running into this problem.
I just published 0.7.0
.
The same problem afflicted me a whole aftertoon ...
Users must update their existing
InterceptHandler
while upgrading to 3.11 (replacelogging.currentframe()
withsys._getframe()
).
All my QA tools including my IDE warns against using _getframe()
as it's an [implementation detail]( which I tend to agree on.
So I looked for an alternative and came up with this, where we immediatly start on the 6th frame. Based on my testing using this method and the current method, I get the same results (please confirm).
depth = 6
frame: FrameType | None = inspect.getouterframes(inspect.currentframe())[depth].frame
Would this be a better choice to use for the InterceptHandler()
example as it's more robust?
The point of using _getframe(6)
was to access the 6th frame directly and avoid iterating through intermediate frames. Using inspect.getouterframes()
will cause them to be iterated and indexed anyway, so we could as well just refactor InterceptHandler
to start iteration at the 1st frame.
hashtag Find caller from where originated the logged message.
frame, depth = inspect.currentframe(), 0
while frame and (depth == 0 or frame.f_code.co_filename == logging.__file__):
frame = frame.f_back
depth += 1
This looks a bit more straightforward. This shouldn't impact performance too much. Eventually, I plan to replace InterceptHandler
with a built-in logger.bridge()
method anyway.