This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Set default argument of logging.disable() to logging.CRITICAL
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: vinay.sajip Nosy List:
Priority: low Keywords: patch

Created on 2016-10-24 21:45 by Al.Sweigart, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
default_critical.patch Al.Sweigart, 2016-10-24 21:45 Implementation of the enhancement, including documentation update review
Messages (11)
msg279341 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2016-10-24 21:45
As a convenience, we could make the default argument for logging.disable()'s lvl argument as logging.CRITICAL. This would make disabling all logging messages:

logging.disable()

...instead of the more verbose:

logging.disable(logging.CRITICAL)

This one-line change is backwards compatible.
msg279346 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016-10-25 02:45
Is disabling all logging messages a common need? Maybe other levels are common but we can't know.

And at least the doc patch needs a versionchanged tag.
msg279347 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-10-25 02:50
Given that a user can add their on levels, I think that having a default would be misleading (having no arguments implies total disabling but with custom levels the default of CRITICAL might not disable all messages).
msg279349 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2016-10-25 03:08
xiang.zhang: The use case I've found is that I often have logging enabled while writing code, and then want to shut it off once I've finished. This might not be everyone's use case, but this is a backwards-compatible change since it's currently a required argument. If there's a sensible default, I think this is it.

rhettinger: We could use sys.maxsize instead of logging.CRITICAL to disable any custom logging levels as well if this is a concern.
msg279350 - (view) Author: Xiang Zhang (xiang.zhang) * (Python committer) Date: 2016-10-25 03:28
> We could use sys.maxsize instead of logging.CRITICAL to disable any custom logging levels as well if this is a concern.

sys.maxsize is not the upper bound limit of integers in Python. There is no such value in Python3.

> The use case I've found is that I often have logging enabled while writing code, and then want to shut it off once I've finished.

How about logger.disabled = True. This can work even if there are custom levels. But it's not a documented feature.
msg279351 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2016-10-25 03:35
> How about logger.disabled = True.

This seems to violate "there should be one and only one way to do it". What happens when logging.disabled is True but then logging.disable(logging.NOTSET) is called? I could see this being a gotcha.

Since logging.CRITICAL is 50, I think it's reasonable to assume that no one would create a logging level larger than sys.maxsize.
msg279355 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-10-25 05:47
Put me down for -0.  I don't think the minor convenience is worth the loss in clarity.
msg279357 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2016-10-25 06:09
As a general indicator, I did a google search for "logging.disable(logging.XXX)" for the different levels. The number of results passing ERROR, WARN, DEBUG, and INFO are under a couple dozen each. But the number of results for "logging.disable(logging.CRITICAL)" is 3,800.

It's a rough estimate, but it shows that 95%+ of the time people call logging.disable() they want to disable all logging.
msg279725 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2016-10-30 15:01
> The use case I've found is that I often have logging enabled while writing code, and then want to shut it off once I've finished.

You could do this by having a configuration which is quite verbose while doing development and then less verbose when in production mode.  Then if an issue crops up in production, verbosity could be temporarily turned up in the production configuration while diagnosing the issue, then turned down again later, without making code changes. Remember that verbosity can be set at the handler level too, which sometimes gives finer-grained control of logging verbosity.
msg280127 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2016-11-06 02:19
Setting up different configurations for dev/prod is a bit more complicated than I'd like for most projects. I'd instead just call logging.disable(logging.CRITICAL).

The entire point of this is just for the convenience of being able to disable logging messages by calling logging.disable() instead of logging.disable(logging.CRITICAL).

It's a two-line change, backwards compatible, and (imo) a sensible default. You call logging.disable() expecting it to disable logging. You might want to disable a lower level, but as the Google search shows, most people just want to disable all logging period.
msg284384 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-12-31 11:40
New changeset 459500606560 by Vinay Sajip in branch 'default':
Closes #28524: added default level for logging.disable().
https://hg.python.org/cpython/rev/459500606560
History
Date User Action Args
2022-04-11 14:58:38adminsetgithub: 72710
2021-11-04 14:31:36eryksunsetmessages: - msg405700
2021-11-04 14:31:21eryksunsetnosy: - ahmedsayeed1982

components: + Library (Lib), - Subinterpreters
versions: + Python 3.7, - Python 3.8
2021-11-04 12:10:49ahmedsayeed1982setversions: + Python 3.8, - Python 3.7
nosy: + ahmedsayeed1982, - rhettinger, vinay.sajip, python-dev, Al.Sweigart, xiang.zhang

messages: + msg405700

components: + Subinterpreters, - Library (Lib)
2016-12-31 11:40:21python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg284384

resolution: fixed
stage: resolved
2016-11-06 02:19:04Al.Sweigartsetmessages: + msg280127
2016-10-30 15:01:47vinay.sajipsetmessages: + msg279725
2016-10-26 15:07:38rhettingersetpriority: normal -> low
assignee: vinay.sajip
versions: + Python 3.7
2016-10-25 06:09:24Al.Sweigartsetmessages: + msg279357
2016-10-25 05:47:32rhettingersetmessages: + msg279355
2016-10-25 03:35:11Al.Sweigartsetmessages: + msg279351
2016-10-25 03:28:57xiang.zhangsetmessages: + msg279350
2016-10-25 03:08:39Al.Sweigartsetmessages: + msg279349
2016-10-25 02:50:13rhettingersetnosy: + rhettinger
messages: + msg279347
2016-10-25 02:45:59xiang.zhangsetnosy: + xiang.zhang
messages: + msg279346
2016-10-24 21:46:17ned.deilysetnosy: + vinay.sajip
2016-10-24 21:45:10Al.Sweigartcreate