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
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 :-/
> Repoze-dev mailing list
Repoze-dev mailing list