Re: [Python-ideas] Logging Levels

2017-11-29 Thread Mike Miller
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:

28.11.17 21:45, Guido van Rossum пише:
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.


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).


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-29 Thread Mike Miller

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:

On 29 November 2017 at 06:46, Mike Miller  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.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Nick Coghlan
On 29 November 2017 at 06:46, Mike Miller  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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Mike Miller
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:

28.11.17 21:45, Guido van Rossum пише:
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.


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).




___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Mike Miller
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.


(i.e. There is no need for note if it has the same effect as info.  We already 
have info.)


-Mike


On 2017-11-28 12:31, Guido van Rossum 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.)



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Guido van Rossum
On Tue, Nov 28, 2017 at 12:17 PM, Serhiy Storchaka 
wrote:

> 28.11.17 21:45, Guido van Rossum пише:
>
>> 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.
>>
>
> 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).
>

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)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Serhiy Storchaka

28.11.17 21:45, Guido van Rossum пише:
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.


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).


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Mike Miller

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:
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.



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Mario Corchero
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  wrote:

> On Tue, Nov 28, 2017 at 11:56 AM, Mike Miller 
> wrote:
>
>> Yes, I remember now.  However, it still outputs with the level name of
>> critical:
>>
>> >>> logging.fatal('hello')
>>
>> CRITICAL:root:hello
>>
>
> Ah, that makes it slightly more complicated -- changing that to print
> FATAL is surely going to break some people's log parsers. :-(
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Guido van Rossum
On Tue, Nov 28, 2017 at 11:52 AM, Mario Corchero 
wrote:

> Not sure if that is what you meant, but here is already "FATAL" which is
> indeed an alias of CRITICAL:
>
> >>> logging.FATAL
> 50
> >>> logging.fatal
> 
>

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)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Mike Miller

Yes, I remember now.  However, it still outputs with the level name of critical:

>>> logging.fatal('hello')

CRITICAL:root:hello



On 2017-11-28 11:52, Mario Corchero wrote:
Not sure if that is what you meant, but here is already "FATAL" which is indeed 
an alias of CRITICAL:


 >>> logging.FATAL
50
 >>> logging.fatal



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Mario Corchero
Not sure if that is what you meant, but here is already "FATAL" which is
indeed an alias of CRITICAL:

>>> logging.FATAL
50
>>> logging.fatal


On 28 November 2017 at 19:45, Guido van Rossum  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 
> wrote:
>
>> 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
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


Re: [Python-ideas] Logging Levels

2017-11-28 Thread Guido van Rossum
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 
wrote:

> 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
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Logging Levels

2017-11-28 Thread Mike Miller

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/