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

Vinay Sajip vinay_sajip at yahoo.co.uk
Fri Dec 10 20:39:08 CET 2010


Bill Janssen <janssen <at> parc.com> writes:

> Liked it just fine -- easier to write.  But nothing came out!  Because
> it's got this odd idea (from Java?) about "severities" of messages, and
> by default passes nothing less "threatening" than warnings, because
> logger.root is initialized by default to WARNING.

The idea about severity of messages is based on the premise that there might be
different audiences for logged messages, and that these can change over time. A
fairly common developer perspective on logging is that a logger equates to a
destination (e.g. console or file) and the only audience for logging is the
developer themselves. So, "handlers" and "loggers" seem complicated, perhaps
over-complicated.

In more complex systems, there are different stakeholders: end users, sys
admins, support teams, development teams. You have to consider "what happened"
(logging event), "where it happened" (logger name), "how important it is"
(severity or level) and "who wants to know" (handler), because not everyone
wants to know about everything all the time. That's pretty independent of which
language you're developing in; it's more a function of the complexity of the
system you're developing. Since Python is used in some fairly large system
scenarios - NASA, Google, etc. - it doesn't make sense not to have the whole
enchilada of logging functionality, at the risk of making it seem complicated to
users with less complex needs. And importance maps reasonably naturally onto an
idea of integer levels.

The default setting of WARNING is not from Java either - it's the Unix idea that
verbosity should be kept to a minimum unless specifically requested. So,
warnings and errors should be shown, but info and debug not. Imagine if the
default level was DEBUG - lots of detailed stuff would be displayed, which would
be off-putting for most users.

Regards,

Vinay Sajip




More information about the Python-Dev mailing list