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

[Ben Finney]

Thomas Heller <th*****@python.netwrites:

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"

Right. So, part of the requirements for using your library now is that
the caller is responsible for configuring logging before using the
library.

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.

The logging system needs to be configured in a way that makes sense
for the application, so it's the application (somewhere near the top
level) that's responsible for configuring it. You're right that this
can't be done without that context; there's no sane default.

You need to document that assumption of your library for those who
will use it.

--
\ “The cost of education is trivial compared to the cost of |
`\ ignorance.� —Thomas Jefferson |
_o__) |
Ben Finney

[Vinay Sajip]

On Aug 26, 8:05 pm, Thomas Heller <[e-mail]:

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]

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

[Vinay Sajip]

On Aug 27, 11:28 am, Thomas Heller <[e-mail]:

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]

Vinay Sajip schrieb:

On Aug 27, 11:28 am, Thomas Heller <[e-mail]:

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

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]

On Aug 29, 11:02 pm, Thomas Heller <[e-mail]:

>
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