[Python-Dev] Using logging in the stdlib and its unit tests

Vinay Sajip vinay_sajip at yahoo.co.uk
Wed Dec 8 02:51:44 CET 2010

Nick Coghlan <ncoghlan <at> gmail.com> writes:

> Indeed - I was very surprised to find just now that calling
> "logging.warn('Whatever')" is not the same as doing "log =
> logging.getLogger(); log.warn('Whatever')".

Don't know why you'd be surprised: it's been that way since logging was added to
Python, and the logging.debug() etc. are documented as convenience methods for
casual use in throwaway scripts, interactive sessions etc. The convenience is in
that you don't need to specify a logger (the root logger is used) and that
basicConfig() is called for you.
> Adding a NullHandler isn't the right thing to do - the behaviour I
> would want for any standard library logging that hasn't been
> explicitly configured otherwise is to do what the root logger does
> under basicConfig(): debug() and info() get suppressed, warn(),
> error(), critical() and exception() go to stderr. It seems to me like
> that would be more useful default behaviour in general than emitting a
> warning about not finding a handler.
> So my suggestion would be:
> 1. In the absence of a "config" call, make the "no handler" path in
> loggers emit messages *as if* basicConfig() has been called (without
> actually calling it)
> 2. Remove the implicit calls to basicConfig() from the module level
> convenience function
> How *feasible* that idea is to implement, I don't know.

What about "Special cases aren't special enough to break the rules."? Why should
logging from stdlib modules be treated differently from the case of logging from
library modules in general? It could be argued that the behaviour you're
proposing is confusing/inconsistent to some people.


Vinay Sajip

More information about the Python-Dev mailing list