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

[Nick Coghlan]

On Wed, Dec 8, 2010 at 6:32 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Thanks for the detailed explanation. I agree that unraisable warnings and errors
> need to be handled somehow. There is a way in which this can be done without
> affecting a logging configuration, viz. logging can define a "handler of last
> resort" (not attached to any logger) which is invoked when there are no
> user-specified handlers. This would by default be a StreamHandler writing to
> sys.stderr with a threshold of WARNING (or perhaps ERROR).

A "handler of last resort" is exactly the kind of concept I had in
mind. Just not expressed quite so succinctly :)

> Thus sounds like a
> better option than a direct write to sys.stderr, since you can't change the
> latter behaviour easily if you want to do something else instead.

Yeah, this is why I can understand Brian's desire to use the logging
module rather than a direct write to stderr in the futures
implementation.

> This is of course a backwards-incompatible change to logging semantics: instead
> of saying that logging will be silent unless explicitly asked to produce output,
> we're saying that logging will always produce output for warnings and errors (or
> perhaps just errors), unless explicitly silenced. This is of course in line with
> the Zen of Python; the present behaviour, which is not so aligned, is based on
> the idea that logging should not affect program behaviour if it's not wanted by
> the program developer (as opposed to library developer).

Libraries that write directly to stderr affect program behaviour as
well - at least with logging, the application developer will have an
easier time of silencing (or redirecting) them.

Also, in situations where this default handler will be used, logging
currently produces output at least once (the warning that it couldn't
find a handler to use).

So while it is a behavioural change, it is one that should be
acceptable from a compatibility point of view.

> It would also mean changing the documentation about NullHandler to say: "If you
> have messages which must get out when you can't raise an exception, then don't
> add a NullHandler to your top-level loggers."

Agreed. We could also make it easy to replace the handler of last
resort so people can easily recover the old behaviour (by inserting
NullHandler in place of the default last resort handler).

Cheers,
Nick.

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