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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
