A new feature is being added in `logging.config.dictConfig()` to configure `QueueHandler` and `QueueListener`

Users
#1

In 3.12, I’m adding a new feature to allow configuration of logging.handlers.QueueHandler and logging.handlers.QueueListener via logging.config.dictConfig(). Here’s the relevant documentation - comments are welcome here or on the PR.

Configuring QueueHandler and QueueListener

If you want to configure a QueueHandler, noting that this is normally used in conjunction with a QueueListener, you can configure both together. After the configuration, the QueueListener instance will be available as the listener attribute of the created handler, and that in turn will be available to you using logging.getHandlerByName() and passing the name you have used for the QueueHandler in your configuration. The dictionary schema for configuring the pair is shown in the example YAML snippet below.

handlers:
  qhand:
    class: logging.handlers.QueueHandler
    queue: my.module.queue_factory
    listener: my.package.CustomListener
    handlers:
      - hand_name_1
      - hand_name_2

The queue and listener keys are optional.

If the queue key is present, the corresponding value can be one of the following:

  • An actual instance of queue.Queue or a subclass thereof. This is of course only possible if you are constructing or modifying the configuration dictionary in code.
  • A string that resolves to a callable which, when called with no arguments, returns the queue.Queue instance to use. That callable could be a queue.Queue subclass or a function which returns a suitable queue instance, such as my.module.queue_factory() .
  • A dict with a '()' key which is constructed in the usual way as discussed here in the documentation. The result of this construction should be a queue.Queue instance.

If the queue key is absent, a standard unbounded queue.Queue instance is created and used.

If the listener key is present, the corresponding value can be one of the following:

  • A subclass of logging.handlers.QueueListener. This is of course only possible if you are constructing or modifying the configuration dictionary in code.
  • A string which resolves to a class which is a subclass of QueueListener , such as 'my.package.CustomListener' .
  • A dict with a '()' key which is constructed in the usual way as discussed here in the documentation. The result of this construction should be a callable with the same signature as the QueueListener initializer.

If the listener key is absent, logging.handlers.QueueListener is used.

The values under the handlers key are the names of other handlers in the configuration (not shown in the above snippet) which will be passed to the queue listener.

Any custom queue handler and listener classes will need to be defined with the same initialization signatures as QueueHandler and QueueListener.

1 Like
#2

Thanks Vinay.