Hi, I use the logging module extensively for even the simplest scripts, one of the reasons there's been less difficulty moving to Python 3 at work. One of the "nano features" I've often added to its config is the addition of a custom log level. Never mentioned it before because of its triviality and minor use cases, but just realized that I've been doing it five years now and happy with it, so why not? NOTE (~35) It is called the "note" level and used when one needs to express something important, yet positive, and have it be output by default. The standard levels don't support this currently, you often have to potentially scare the end user with a warning or higher to have a message emitted. Typically I use it to return important information that was asked for specifically and retrieved successfully, e.g.: log.note('Your token is: %s', token) log.note(f'⏵ {item.id} {item.name}') There are other examples. Sphinx, has the concept of note admonitions for docs in addition to warning and danger. Bootstrap has note banners for web/apps. There is something important to express or highlight, but nothing to worry about. FATAL (alias of CRITICAL) Can't find it now, but believe the docs in the past stated that CRITICAL was meant for *unrecoverable* errors. I've never had a project where I didn't shut down immediately after such an occurrence. Therefore I find "FATAL" a more accurate description of what happened. Log4j and other industry loggers use this level name as well. There is also an aesthetic reason to prefer "fatal". It is shorter and so aligns better with other level names for readability, e.g.: console_format = ' %(levelname)-7.7s %(message)s' Tried but never found a good abbreviation for critical, unfortunately. The other option is to add length to align the field. Most messages use the shorter level names (debug, info) so extra length results in wasted space that is very rarely needed. Hopefully someone else finds these useful. Neither depends on the other. -Mike
These look like good improvements. I think you should make an issue on bugs.python.org describing your proposal and if you can submit a PR that implements it. On Tue, Nov 28, 2017 at 11:25 AM, Mike Miller <python-ideas@mgmiller.net> wrote:
-- --Guido van Rossum (python.org/~guido)
Yep, I personally prefer fatal so I'd be totally in for it. But as you said I can see an issue on the tools that work around the logs produced (typical alerting/monitoring around an app) and all the logs parsing stacks. On 28 November 2017 at 19:59, Guido van Rossum <guido@python.org> wrote:
On Tue, Nov 28, 2017 at 11:52 AM, Mario Corchero <mariocj89@gmail.com> wrote:
Maybe it should just go the other way around, making critical an alias for fatal, and switching them around in the docs? No code will be invalidated but it will encourage people to use the simpler, more direct term. -- --Guido van Rossum (python.org/~guido)
Thanks, will do, after some time for folks to comment further. One question was how will the level integer id affect custom levels defined by applications? If a clash could cause an issue, perhaps adding it above the last one at 100(?) makes more sense. -Mike On 2017-11-28 11:45, Guido van Rossum wrote:
28.11.17 21:45, Guido van Rossum пише:
See https://bugs.python.org/issue31732 It was discussed and rejected. Citing Raymond: "Overall, this seems rehash and second guess the discussions and decisions made 15 years ago when PEP 282 was accepted." The set of logging levels is not closed. The user can extend it to cover more specialized uses by logging.addLevelName(). There are disadvantages of having too much standard names for logging levels (as we can see in Java).
On Tue, Nov 28, 2017 at 12:17 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
OK, that's a reasonable discussion, let's not do this. Also I note that in my own usage, "note" comes below "warning", not above it. E.g. mypy has three levels for its end-user facing messages: error, warning, and note. (Note that mypy does not use the logging module -- but it would still feel odd to me to see "note" between warning and error rather than below warning.) -- --Guido van Rossum (python.org/~guido)
On 29 November 2017 at 06:46, Mike Miller <python-ideas@mgmiller.net> wrote:
Hi, the reason I use note is that I want it to be output by default. So it must be above warning, or perhaps the default level changed.
If the message to be displayed is part of the actual UX of a command line tool, our advice is "You don't want the logging module, you want the print() builtin": https://docs.python.org/3/howto/logging.html#when-to-use-logging As a relevant technical detail, it's also worth noting that the default handler emits messages on stderr, while CLI UX messages should generally be displayed on stdout. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi, As mentioned, using logging everywhere has some advantages. It doesn't have to be added later on, and it avoided a decent fraction of the work porting to Python 3. Have found users tend to like the labeling of messages, from INFO to ERROR. We skip the time stamp on the console and send to stdout. And with a new-file template, it isn't a burden to set it and argparse up in new scripts. (--verbose etc) -Mike On 2017-11-28 20:45, Nick Coghlan wrote:
I think the resistance to trace is that it splits an existing level into two, supporting "level inflation." The current level name of critical is similar, describing not just an error, but a really big error! Note (as described here), handles an additional use case. I don't consider it level inflation. -Mike On 2017-11-28 12:17, Serhiy Storchaka wrote:
Hi, IMHO the prior decision(s) are too conservative. Reading the bugs, we can see lots of folks reinventing the wheel with common use cases for no good reason. I also gave examples in the log4j, docs, and web apps world that these levels are recognized needs. An addition would represent a very tiny fractional increase in the complexity of the logging module, from ~6 to ~8 in one small corner. It's not like we're adding human expressions to cats and piles of poo here are we? ;-) The builtin java logging suffers from backwards compatibility with an awkward initial design. log4j doesn't (nor we) have that problem, but it includes some cases suggested. In short, have been using note and fatal for years productively. Not a strong proponent of trace and have survived without it so far, but if it were there I'd have used it a few times over the years. On 2017-11-28 12:17, Serhiy Storchaka wrote:
These look like good improvements. I think you should make an issue on bugs.python.org describing your proposal and if you can submit a PR that implements it. On Tue, Nov 28, 2017 at 11:25 AM, Mike Miller <python-ideas@mgmiller.net> wrote:
-- --Guido van Rossum (python.org/~guido)
Yep, I personally prefer fatal so I'd be totally in for it. But as you said I can see an issue on the tools that work around the logs produced (typical alerting/monitoring around an app) and all the logs parsing stacks. On 28 November 2017 at 19:59, Guido van Rossum <guido@python.org> wrote:
On Tue, Nov 28, 2017 at 11:52 AM, Mario Corchero <mariocj89@gmail.com> wrote:
Maybe it should just go the other way around, making critical an alias for fatal, and switching them around in the docs? No code will be invalidated but it will encourage people to use the simpler, more direct term. -- --Guido van Rossum (python.org/~guido)
Thanks, will do, after some time for folks to comment further. One question was how will the level integer id affect custom levels defined by applications? If a clash could cause an issue, perhaps adding it above the last one at 100(?) makes more sense. -Mike On 2017-11-28 11:45, Guido van Rossum wrote:
28.11.17 21:45, Guido van Rossum пише:
See https://bugs.python.org/issue31732 It was discussed and rejected. Citing Raymond: "Overall, this seems rehash and second guess the discussions and decisions made 15 years ago when PEP 282 was accepted." The set of logging levels is not closed. The user can extend it to cover more specialized uses by logging.addLevelName(). There are disadvantages of having too much standard names for logging levels (as we can see in Java).
On Tue, Nov 28, 2017 at 12:17 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
OK, that's a reasonable discussion, let's not do this. Also I note that in my own usage, "note" comes below "warning", not above it. E.g. mypy has three levels for its end-user facing messages: error, warning, and note. (Note that mypy does not use the logging module -- but it would still feel odd to me to see "note" between warning and error rather than below warning.) -- --Guido van Rossum (python.org/~guido)
On 29 November 2017 at 06:46, Mike Miller <python-ideas@mgmiller.net> wrote:
Hi, the reason I use note is that I want it to be output by default. So it must be above warning, or perhaps the default level changed.
If the message to be displayed is part of the actual UX of a command line tool, our advice is "You don't want the logging module, you want the print() builtin": https://docs.python.org/3/howto/logging.html#when-to-use-logging As a relevant technical detail, it's also worth noting that the default handler emits messages on stderr, while CLI UX messages should generally be displayed on stdout. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi, As mentioned, using logging everywhere has some advantages. It doesn't have to be added later on, and it avoided a decent fraction of the work porting to Python 3. Have found users tend to like the labeling of messages, from INFO to ERROR. We skip the time stamp on the console and send to stdout. And with a new-file template, it isn't a burden to set it and argparse up in new scripts. (--verbose etc) -Mike On 2017-11-28 20:45, Nick Coghlan wrote:
I think the resistance to trace is that it splits an existing level into two, supporting "level inflation." The current level name of critical is similar, describing not just an error, but a really big error! Note (as described here), handles an additional use case. I don't consider it level inflation. -Mike On 2017-11-28 12:17, Serhiy Storchaka wrote:
Hi, IMHO the prior decision(s) are too conservative. Reading the bugs, we can see lots of folks reinventing the wheel with common use cases for no good reason. I also gave examples in the log4j, docs, and web apps world that these levels are recognized needs. An addition would represent a very tiny fractional increase in the complexity of the logging module, from ~6 to ~8 in one small corner. It's not like we're adding human expressions to cats and piles of poo here are we? ;-) The builtin java logging suffers from backwards compatibility with an awkward initial design. log4j doesn't (nor we) have that problem, but it includes some cases suggested. In short, have been using note and fatal for years productively. Not a strong proponent of trace and have survived without it so far, but if it were there I'd have used it a few times over the years. On 2017-11-28 12:17, Serhiy Storchaka wrote:
participants (5)
-
Guido van Rossum -
Mario Corchero -
Mike Miller -
Nick Coghlan -
Serhiy Storchaka