Calling getLogger results in an *atexit* hook related to a handler being registered for the current Python process. It might also, depending on its mood, print to stdout. These things make it miserable to actually unit test any application which calls getLogger. See also http://plope.com/Members/chrism/logging_blues
That said, you can pass in a logger instance to the Configurator as a debug logger (as the debug_logger parameter) if you need to replace it to capture logging output of BFG itself during a "unit test" (more likely a functional test really). If you're currently using the debug logger for your own application, and that's why you need to replace it within a unit test, maybe just don't use it. Just use getLogger and accept its evilness or construct your own logger instance by hand. No object within repoze.bfg.log is an API. The debug logger is meant for internal use by BFG only. On Fri, 2010-08-06 at 17:22 +0100, Chris Withers wrote: > Hi All, > > Is there any reason why repoze.bfg.log:make_stream_logger manually > instantiates a logger rather than doing logging.getLogger(name)? > > It makes it harder than it needs to be to replace the handlers of the > logger for unit testing purposes :-/ > > cheers, > > Chris > > _______________________________________________ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev > _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
