[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

STINNER Victor added the comment: Vinay: > That code in the wild that sets the level attribute directly is wrong and > should be changed, right? The documentation has always been clear that > setLevel() should be used. If we now take steps to support setting the level > via attribute, isn't

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

Change by Doug Hellmann : -- nosy: +doughellmann ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

Vinay Sajip added the comment: > Obviously the fix could be just to stop doing that in the standard library Well, that's the right fix, and thanks for spotting it. I've applied those changes (42b6c5d and 19c42fb) to the master, 3.8 and 3.7 branches. -- __

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

Zane Bitter added the comment: In turns out that setting the level directly is used in the standard library, so we definitely have a bug here that needs fixing in 3.7 & 3.8. Obviously the fix could be just to stop doing that in the standard library, but I'd argue that this is even stronger e

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

Vinay Sajip added the comment: > are we here to punish people No, that's not what I'm saying. But it's not a priority to support situations where people don't follow published APIs and still expect things to work the way they would like. I would prefer people to use setLevel(), as it helps t

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

Zane Bitter added the comment: > It feels wrong to do this as a band-aid to help out people who didn't do the > right thing. I mean... are we here to punish people for making mistakes by sending them to schroedinbug purgatory, or are we here to help them upgrade to the latest Python without

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

Vinay Sajip added the comment: > There's no way to be sure. But if you have a public (i.e. > non-underscore-prfixed) attribute then some percentage of people are going to > set it, particularly if it seems to work. Well, reading it isn't problematic, so there's no leading underscore. (The s

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

Zane Bitter added the comment: > That code in the wild that sets the level attribute directly is wrong and > should be changed, right? It definitely should be changed (and in our case we did change it once we found it). Whether it's "wrong" is more of a philosophical question ;). But the pr

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

Vinay Sajip added the comment: That code in the wild that sets the level attribute directly is wrong and should be changed, right? The documentation has always been clear that setLevel() should be used. If we now take steps to support setting the level via attribute, isn't that encouraging b

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

Change by Zane Bitter : -- keywords: +patch pull_requests: +15008 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15286 ___ Python tracker ___

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

Change by SilentGhost : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue37857] Setting logger.level directly has no effect due to caching in 3.7+

New submission from Zane Bitter : This is a related issue to bug 34269, in the sense that it is also due to the caching added by the fix for bug 30962. In this case, the bug is triggered by setting the public 'level' attribute of a logging.Logger object, instead of calling the setLevel() meth