> 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?