Greg Werbin <outth...@me.gregwerbin.com> added the comment:
> Users certainly don't need an API change to prevent that, should they wish
> to. The following simple call will suffice (using 'gnupg' just as an example):
>
> logging.getLogger('gnupg').setLevel(logging.CRITICAL + 1)
This selectively _disables_ a logger. That isn't the same thing as selectively
_enabling_ only the loggers you want to enable.
Something like this would be equivalent to this proposal:
logging.basicConfig(format='...', level=logging.CRITICAL + 1)
logging.getLogger('my_app').setLevel(logging.INFO)
> My point was, they don't need to configure non-root loggers (in terms of
> adding handlers) because the root logger's handlers will normally be used for
> all loggers.
That's fair enough, but why make people do the above (which is somewhat
unintuitive), when they could instead just do this:
basicConfig(format='...'. level=logging.INFO, logger='my_app')
Moreover, what if you want multiple different formatters and handlers for
different sub-loggers?
Sure, you could use dictConfig(), but why force people to do this:
logging.dictConfig({
'formatters': {
'format1': {'format': '...'},
'format2': {'format': '...'},
'format3': {'format': '...'},
},
'handlers':
'handler1': {'class': 'logging.StreamHandler', 'formatter':
'format1'},
'handler2': {'class': 'logging.StreamHandler', 'formatter':
'format2'},
'handler3': {'class': 'logging.StreamHandler', 'formatter':
'format3'},
},
'loggers': {
'my_app': {'level': 'WARNING', 'handlers': ['handler1']},
'my_app.client': {'level': 'INFO', 'handlers': ['handler2']},
'my_app.parser': {'level': 'INFO', 'handlers': ['handler3']},
}
})
When they could instead do this:
basicConfig(format='...', level=logging.WARNING, logger='my_app')
basicConfig(format='...', level=logging.INFO, logger='my_app.client')
basicConfig(format='...', level=logging.INFO, logger='my_app.parser')
Not to mention the confusing bug-trap that is the `incremental` option in
dictConfig().
> As you can see, it's not needed for the purpose you described (avoiding
> messages from third-party loggers).
Not "needed", of course. Plenty of people have been logging in Python for years
without it!
But IMO it's a _better_ way to do it compared to the current solutions.
I believe that this proposal could even become the "one obvious way to do it":
run `basicConfig(logger=my_logger)` on the top-level logger in your application.
My perspective is one of being an application developer, ad-hoc "script
developer", and being active helper in many Python forums and chatrooms. I've
seen ugly misuse of logging in serious application developed by serious
organizations, by people who are not full-time Python devs, that would have
been largely avoided by having an "easy" entry point like this. And I've seen
countless newbies intimidated and scared away from logging "properly" in Python
because of the complexity and non-obviousness of the existing interfaces.
I'm open to alternative suggestions of course. But I maintain that the current
dictConfig() is not a suitable alternative, nor is selectively disabling
loggers.
I am very aware of the high maintenance burden on the Python stdlib already, so
I understand the resistance to adding new functionality. From my perspective,
this is a very simple addition, can be tested with a small number of additional
test assertions, and can be easily covered by in the type stubs.
I could also publish this as a separate package on PyPI. If you think this
proposal places an undue burden on Python implementation developers, then I'll
happily drop the PR and publish my own thing. But why reinvent the wheel,
especially for something so small?
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue45027>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
