Recently tried to use the logging configuration file format as
understood by logging.config.fileConfig() and found it very unwieldy for
normal usage. I feel it needs to "scale down" better. Some thoughts:

a) It creates handlers whether they're needed or not. This means you
cannot leave the handler sections present in your configuration file and
just disable and enable the logger by changing the level, or your
application will open the files/sockets etc. anyway, whether the loggers
are enabled or not. This is bordering on being a bug rather than just an
annoyance...

b) There is a lot of unnecessary cruft. For example it should be
possible to eliminate the [loggers], [handlers] and [formatters]
sections. I gather they're there due to a limitation of ConfigParser but
I assume this is historical as I can see no good reason for it now.
Also, entries should default sensibly, e.g. "qualname" should not be
treated as vital but should default to the name in the section header.

c) I'd also suggest providing a newer, non-back-compatible format
alongside the existing one that was less wordy for normal use. Get rid
of the separate "handlers" and "formatters" and make each logger have a
section of its own containing all "handling" and "formatting"
information: most users aren't going to want to think about these things
as separate entities and in any case there is the hierarchical mechanism
to prevent too much copying.

In fact, I'd suggest extending the "basicConfig" idea to be able to call
it on individual loggers, and build a new format around that, where each
section is read and a logger created with the contents passed as keyword
arguments to "basicConfig".

I might have time to do some of this myself but I want to be sure people
think it's a good idea before investing time in it.