logging - how to use in a library?

[Thomas Heller]

Vinay Sajip schrieb:

> Suppose a user of logging configures it wrongly by mistake, so that
> there are no handlers configured. In this case, if the logging system
> were not to output anything at all, then you would have no information
> at all about why - leading to a longer time to diagnose the problem.
> That's the only reason why the message is there, and it's output when
> there are no handlers found for an event, and logging.raiseExceptions
> is 1/True (=> a non-production environment), and
> Logger.manager.emittedNoHandlerWarning is 0/False (to avoid printing
> the message multiple times). As Ben Finney has said, an application's
> logging requirements are the determining factor; and I agree that it's
> not a good idea to do logging configuration in the library, which
> could conflict with what an application developer expects. So
> documenting your logging assumpstions is a good approach.

Well, in my library logging is not used to notify the application user
of problems in the library or so, it is used to give the application
developer who is using my library a chance to find out what the library
is doing without the need to step through the code.

So, in my case a call to logger.error or logger.warning does not mean that the
application is using the library in a wrong way, instead it means that
something isn't working in a certain way.  These 'errors' or 'warnings'
are handled by the library itself.

Unexpected exceptions are not catched by the library, of course.


I came up with a workaround that seems to do what I want.  I add a NULL handler
to my top-level logger which is not the root logger but a logger named 'comtypes',
other loggers are named 'comtypes.something...'.  So the application developer
using the library will not see any comtypes logger messages at all, unless
he calls 'logging.basicConfig()', for example.

> The default level for logging is WARNING, not ERROR - this was judged
> to be a good default level, since under most circumstances we're
> particularly interested in warnings and errors. (A level of WARNING
> catches ERROR and CRITICAL events, too, of course.)

Sure - mistake on my side.

Thanks,
Thomas