[issue34269] logging in 3.7 behaves different due to caching

Vinay Sajip added the comment: > But, seems like one has no public api to reinitialize logging to a like-fresh > state For the use case of testing, you could use a context manager approach as described here in the logging cookbook:

[issue34269] logging in 3.7 behaves different due to caching

Thomas Waldmann added the comment: I agree that we should not dig that deep into logging internals and clear that dict from borg code. But, seems like one has no public api to reinitialize logging to a like-fresh state, right? So maybe THAT is the real problem. Add some .reset() method to

[issue34269] logging in 3.7 behaves different due to caching

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34269] logging in 3.7 behaves different due to caching

Karthikeyan Singaravelan added the comment: Okay, I did some code search on GitHub for `logging.Logger.manager.loggerDict.clear()` (https://github.com/search?q=logging.Logger.manager.loggerDict.clear%28%29=Code) and there was some code in the test_logging where it was used in tearDown and

[issue34269] logging in 3.7 behaves different due to caching

Vinay Sajip added the comment: Well, loggerDict is an internal implementation detail which shouldn't be directly called by the code in borgbackup. Hence I'm not sure you can call it a bug. When messing around with internals of objects, caveats apply. Note that loggerDict isn't mentioned in

[issue34269] logging in 3.7 behaves different due to caching

Change by Karthikeyan Singaravelan : -- versions: +Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34269] logging in 3.7 behaves different due to caching

Karthikeyan Singaravelan added the comment: I think I have found the bug. When we call setLevel then to clear the cache value of Logger objects `logging.Logger.manager.loggerDict.values()`

[issue34269] logging in 3.7 behaves different due to caching

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34269] logging in 3.7 behaves different due to caching

Thomas Waldmann added the comment: https://github.com/borgbackup/borg/pull/3998 Looks like this fix to our test tearDown method makes the tests work again. If one looks at what this dirty/problematic hack was done, it might be because of a missing logging reset functionality? --

[issue34269] logging in 3.7 behaves different due to caching

Change by Thomas Waldmann : -- components: +Library (Lib) type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing

[issue34269] logging in 3.7 behaves different due to caching

New submission from Thomas Waldmann : When running the borgbackup tests on 3.7.0, quite some tests will be broken because expected log output is not emitted. I traced this down up the point when I noticed that reverting the caching feature change of isEnabledFor method in Logger makes the