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

Vinay Sajip vinay_sajip at yahoo.co.uk
Tue Dec 7 21:26:06 CET 2010


This issue was brought to my notice today:

http://bugs.python.org/issue10626

and reference was made in the comments to possible obstacles facing stdlib
maintainers who might wish to use logging in the stdlib and in its unit tests.

>From my perspective and as mentioned in the logging documentation, library code
which uses logging should add a NullHandler instance to any top-level logger,
which will avoid any "No handlers could be found for logger XXX" message if no
logging handlers have been set up. This applies to stdlib code, too, though it
would be good if a logger namespace could be agreed for stdlib usage. (The
logging package itself uses the logger "py.warnings" to redirect warnings to
logging when configured to do so. Perhaps we could standardize on "py.XXX" for
stdlib usage?)

I would suggest that when unit testing, rather than adding StreamHandlers to log
to stderr, that something like TestHandler and Matcher from this post:

http://plumberjack.blogspot.com/2010/09/unit-testing-and-logging.html

This will allow assertion checking of logged messages without resorting to
StringIO, getvalue() etc. If people think it's a good idea, I can add the
TestHandler/Matcher classes to the unit test infrastructure (they wouldn't
become part of the public API, at least until 3.3, but I presume they could be
used in the stdlib unit tests).

On the question of using logging in the stdlib and its unit tests, I would like
to throw this open to python-dev: is there anyone here who wants to use logging
but feels that they can't because of some shortcoming in logging? AFAIK there
should be no obstacles. The preferred approach in stdlib code is as I have
outlined above: add a NullHandler to top-level loggers to avoid
misconfiguration, document the logger names you use, and avoid adding any other
handlers by default. For unit testing, add a TestHandler (or equivalent) to your
top-level logger at the start of the test, make any assertions you need to
regarding what has been logged, remove the handler and close it at the end of
the test. I don't believe there is any inherent conflict or incompatibility
between logger usage in the stdlib, use of logging assertions in unit tests and
use of handlers by application code, but I am happy to have any mistake on my
part pointed out.

>From what I've seen, concurrent.futures adds a StreamHandler which is removed in
the unit test and replaced by StreamHandler pointing to a different stream.
This, I believe, should be changed in line with what I've said above.

Comments?

Regards,

Vinay Sajip



More information about the Python-Dev mailing list