logging - how to use in a library?

[Thomas Heller]

I'm using the logging module in my comtypes library to log
'interesting' things that happen. In other words, the idea
is if the user of the library is interested in the details that
happen in the package internally, he (she?) would configure
a logging level and handlers that write the log messages where it
is convenient.

This works great, with one exception:
If the script using the library does NOT configure logging, and somewhere the library calls
logger.error(...) or logger.critical(...) then he gets a message on stderr saying:

No handlers could be found for logger "foo"

Of course this can be avoided by configuring a NULL-Handler, or raising the
loglevel to a very high value - but why is this necessary?
I would assume that if no handlers are configured than simply the logging
package should not output anything...

Why does logging insist on a default level of ERROR even if unconfigured, and
why does it insist to output something even if no handler is defined?

I assume it would not be a good idea to configure logging in the library itself,
possibly overwriting explicit configuration that the user has done... I don't get it.

Thomas

 

[Vinay Sajip]

I'm using theloggingmodule in my comtypes library to log
'interesting' things that happen. In other words, the idea
is if the user of the library is interested in the details that
happen in the package internally, he (she?) would configure
alogginglevel and handlers that write the log messages where it
is convenient.

This works great, with one exception:
If the script using the library does NOT configurelogging, and somewhere the library calls
logger.error(...) or logger.critical(...) then he gets a message on stderr saying:

No handlers could be found for logger "foo"

Of course this can be avoided by configuring a NULL-Handler, or raising the
loglevel to a very high value - but why is this necessary?
I would assume that if no handlers are configured than simply thelogging
package should not output anything...

Why doeslogginginsist on a default level of ERROR even if unconfigured, and
why does it insist to output something even if no handler is defined?

I assume it would not be a good idea to configureloggingin the library itself,
possibly overwriting explicit configuration that the user has done... I don't get it.

Thomas

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.

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.)

Best Regards,


Vinay Sajip

 

[Thomas Heller]

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

 

[Vinay Sajip]

Vinay Sajip schrieb:

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.

This is a good solution - I'll add this as a suggestion in the
documentation.

Regards,

Vinay Sajip

 

[Thomas Heller]

This is a good solution - I'll add this as a suggestion in the
documentation.

Cool.

BTW: Let me say that the more I use logging the more I like it.
logging is a fantastic package!

Thanks,
Thomas

 

[Vinay Sajip]

BTW: Let me say that the more I useloggingthe more I like it.loggingis a fantastic package!

Thank you, I can say the same for ctypes and py2exe

Regards,

Vinay Sajip