On 12/27/2010 7:29 AM, Vinay Sajip wrote:
The logging configuration calls fileConfig and dictConfig disable all existing
loggers, and enable only loggers explicitly named in the configuration (and
their children). Although there is a disable_existing_loggers option for each
configuration API, which can be used to prevent disabling of existing loggers,
the default value of this option is True (for backward compatibility) and so
existing ("old") loggers are disabled by default.
Good that you recognized the bigger issue than 10626, and are wanting to
address it.
It would be interesting to hear the use case for calling fileConfig
and/or dictConfig and/or basicConfig more than once anyway (although I
guess basicConfig doesn't disable anything). That might shed some light
on the approach that should be taken.
My "intuitive" thought about the matter is that loggers, once enabled,
shouldn't be disabled except explicitly by name, not implicitly by a
flag parameter. So I'd expect a parameter that takes a list of loggers
to disable, rather than a flag whose default value disables all of
them. Of course this doesn't address the how and why of backward
compatibility needs.
Part of the problem, perhaps, is that stdlib loggers might be enabled
before the application gets to its logging configuration call, and those
would then be disabled accidentally.
As I prepare to add logging to my web application this week, I've only
found the need to initialize logging in one place and at one time... I
doubt that any of the loggers you mentioned as being in the 3.2 stdlib
will have been enabled by then, so I'll not have a problem, but if they
proliferate, I could eventually in future versions. Granted, my
application will likely be one of the simpler applications of logging,
at least initially.
While I agree it would be nice to have a stdlib logger naming convention
of some sort, I don't think the naming convention should be used to
implicitly not disable particular loggers. The only difference between
stdlib and 3rd party libraries is whether they've become stable enough
and useful enough for the whole Python community; many 3rd party
libraries are quite stable enough and useful enough for particular
applications, and could have similar issues as the stdlib regarding
logger configuration.
Having an API to disable loggers using an explicit list would require a
corresponding API to obtain from logging the list of currently enabled
loggers, and perhaps currently disabled ones as well? That way, if an
application truly wanted to disable all currently enabled loggers, they
would have an easy way to know the list... and perhaps the list of
loggers they disable during configuration should be the first thing that
is logged as a result of the xxxConfig API? Then, at least, they would
not be ignorant of the accidental disabling. I guess even if the
parameter were left as a default flag to turn off all loggers, if the
list were logged, that would be alerting. But some applications may not
expect such a log entry.... but maybe that is the least instrusive
backwards-compatible action that can be taken, because if an application
does configure logging, they likely do expect to have log messages to
view/process.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
