Non-blocking handlers for logging

In contrast to existing frameworks for logging from within Python’s asyncio, noblklog works hard to provide a implementation that just works as is. It will not require to learn and use a different logging API with caveats different from the standard library. The handlers it provides can be used with any application built on logging by simply changing the logging configuration.

How to install?

There`s absoluelty no magic here. Just the usual. No compiling required either:

$ pip install noblklog

How to use?

Even less magic (wait for it: there’ll be some later on) and answering this question depends on your enviroment and preferences.

For taking it for a quick ride while testing or in scripts the commonly used basicConfig() is your best bet:

import asyncio
import logging
import noblklog

logging.basicConfig(
    level=logging.INFO,
    handlers=[
        noblklog.AsyncStreamHandler(),
    ],
)
log = logging.getLogger(None)

log.info('Here comes that magic we promised!')

async def main():
    log.info('Even more magic!')

asyncio.run(main())

If you build a more sophisticated application it is quite propable that at one point you might provide configurable logging using fileConfig() or dictConfig(). Maybe like this.

import asyncio
import logging
import logging.config
import pathlib

logging.config.fileConfig(
    pathlib.Path(__file__).with_suffix('.ini').open()
)
log = logging.getLogger(None)

log.info('Here comes that magic we promised!')

async def main():
    log.info('Even more magic!')

asyncio.run(main())

And this.

[handlers]
keys=console

[handler_console]
class=noblklog.AsyncStreamHandler
formatter=default

[formatters]
keys=default

[formatter_default]
format=%(asctime)s %(levelname)s %(message)s
datefmt=

[loggers]
keys=root

[logger_root]
level=NOTSET
handlers=console

Where else can I send log messages?

See the Library API part of the documentation.

Anything to look out for?

Yes. Don’t log too much. To preserve order of log messages while still being able to keep it’s promise of being non-blocking, noblklog will sometimes have to queue messages. This is only necessary if the handler’s destination file descriptor (temporarily) won’t accept writes. Log too many and/or too big messages and this will happen. If you just keep on logging the message queue will eat your memory.

In practice for normal sized software components with run of the mill logging behaviour this is not a problem that will surface. If you’re still afraid see the max_queued parameters on the logging handlers. Setting that will risk lost messages, though. If that’s also not an option you probably need a custom logging solution.