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

[Antoine Pitrou]

On Wed, 8 Dec 2010 12:15:53 +0000 (UTC)
Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> > First, you cannot call it a "default", since the library writer has to
> > make it explicit.
> > Second, I don't find that convenient at all. When I use a third-party
> > lib I want the errors to be displayed, not silenced. I'm willing to bet
> > that most people have the same expectation. *Especially* when
> > prototyping, since you're not sure you've got everything right.
> > 
> > So, that's two problems:
> > - the library author has to explicit activate what you argue is a
> >   "default" behaviour (otherwise the library user gets an unhelpful
> >   message that handlers are not configured)
> > - the library user still has to override that "default" since it's not
> >   satisfying for most uses
> > 
> 
> See my comments to Nick Coghlan's post about getting messages out when you can't
> raise an exception. I think the case is not as common as you suggest (because in
> many instances, you would raise an exception to signal an error).

I'm not talking specifically about exceptions, but about errors in
general. If the case wasn't common, I'm not sure why the error() and
critical() methods would exist at all.

(of course I'm assuming error() is meant to output error messages. If
that's a wrong interpretation then I'm a bit puzzled :-))

> > There's a third problem with it:
> > - all this is not easily discoverable. You cannot expect each user of a
> >   third-party lib to *also* read the logging docs in addition to the
> >   third-party lib docs. On my Web browser,
> >   http://docs.python.org/dev/library/logging.html seems to be at least
> >   50 pages long.
> 
> You're complaining about too much documentation?! Don't measure it by weight!
> Seriously, I don't see what's wrong with a library developer reading the
> documentation for any module they're using, logging included.

I was talking about the user of a library, not its developer (see the
snippet quoted above).

> The
> user of the library only needs to know what logger names are used by that
> library, and that too only if they want to configure those loggers.

The thing is, they don't *want* to configure them, but you force them
to do some configuration if they don't want error messages to be
silenced.

> > For a comparison, the warnings module logs all warnings by default on
> > stderr without requiring any a priori configuration. And that's what
> > stderr is for (reporting errors).
> > 
> 
> But that behaviour is *not* always wanted.

Sure. What I'm arguing is that the warnings module's default behaviour
is much more useful than the logging module's default behaviour.

> That's why I was asked to add
> warnings integration to logging - to redirect warning messages to logging.

That's a separate topic :)

> (b) For this case, since there's no telepathy in this world, you need some way
> for the programmer to communicate their intent about the logging level, or
> format string, or log file that they want to use.

Well, the programmer doesn't have to communicate their intent about
what and how warnings get displayed by default, and I'm not sure the
warnings module has a telepathy routine inside (although you never
know, since IIRC Brett did some philosophy studies).

Regards

Antoine.