[Python-Dev] Using logging in the stdlib and its unit tests (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Dec 8 02:00:50 CET 2010

On Wed, Dec 8, 2010 at 10:09 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Tue, 7 Dec 2010 23:45:39 +0000 (UTC) Vinay Sajip <vinaysajip at yahoo.co.uk> wrote:

Antoine Pitrou <solipsis pitrou.net> writes:

> > I thought "error" and "critical" messages were logged to stderr by > default? Isn't it the case? > Only if you call basicConfig() or use the logging.debug(), logging.info(), etc. module-level convenience functions (which call basicConfig under the hood). Why wouldn't it be the default for all logging calls ? Such special cases don't really make things easy to remember.

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')".

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.

Cheers, Nick.

Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list