`logging.basicConfig` should support parameter `formatter_class` (currently instantiates hardcoded `logging.Formatter`)

[hartwork]

Hi! 👋

Currently logging.basicConfig instantiates logging.Formatter as a formatter:

cpython/Lib/logging/__init__.py

Line 2111 in 3dfed23

fmt = Formatter(fs, dfs, style)

Now if the developer wants a different formatter class, they have to let logging.basicConfig create the default formatter first and then replace it passing the same parameters:

import logging

class CustomFormatter(logging.Formatter):
    ...  # custom code here

format_ = "......."  # arbitrary

logging.basicConfig(format=format_)

formatter = CustomFormatter(fmt=format_)
for handler in logging.root.handlers:
    handler.setFormatter(formatter)

A version of that with the blanks filled in can be seen at https://gist.github.com/hartwork/8b5963b5e9a698a3d6d352c657418af3 .

A brittle alternative would be use of inittest.mock.patch:

import logging
from inittest.mock import patch

class CustomFormatter(logging.Formatter):
    ...  # custom code here

with patch("logging.Formatter", CustomFormatter):
    logging.basicConfig(format=".......")

None of that is ideal. With a new parameter formatter_class, the code would be written as this:

import logging

class CustomFormatter(logging.Formatter):
    ...  # custom code here

logging.basicConfig(format=".......", formatter_class=CustomFormatter)

I hope that you are open to this suggestion, and I will open a related pull request in a minute.

Thanks! 🙏

Linked PRs

• gh-133577: Add parameter formatter to logging.basicConfig #133578

[vsajip]

Well, the idea is that basicConfig is meant for very basic configuration needs, where a hardcoded Formatter class seems reasonable. You could always use dictConfig() to configure a specific formatter class; your suggestion wouldn't help if the formatter __init__ needed anything other than the default API signature that Formatter has. So it's a limited solution-of-sorts where other configuration options are already available. For that reason, I'm not keen on this change. But thank you for trying to improve things!

[hartwork]

Hello @vsajip, thank for your quick reply!

your suggestion wouldn't help if the formatter __init__ needed anything other than the default API signature that Formatter has.

@vsajip it only dictates three parameters, CustomerFormatter.__init__ would still be free to have additional key-value arguments with defaults and also use of formatter_closs=functools.partial(......) or a closured class would allow working around the limitations further where needed.

Passing an instance a la formatter=CustomFormatter(.....) instead of a class would be an alternative that also helps the case and does not have the limitations that you voice econcerns about. I have updated #133578 now to demo that approach in practice. Could you have a look?

Well, the idea is that basicConfig is meant for very basic configuration needs, where a hardcoded Formatter class seems reasonable.

Looking at how existing arguments filemode, encoding, errors all allow customizing the auto-created FileHandler I do not feel that that logging.basicConfig is fair to consider truly basic in 2025 — it is a versatile tool already, just the name remains from a past time in my view. It would have been possible back then to argue that handlers already allowed that to work in Python >=3.3 and the introduction of handlers in 3.3 could have been rejected the same way arguing that it's not basic enough for basicConfig but it was considered of enough value (which I support). Supporting custom formatters conveniently is the potentially last missing piece to complete logging.basicConfig, and it's a trivial fix. I don't see why it needs to be this hard to use basicConfig with a customer formatter and also no reasons to go full dictConfig for something so simple. Thanks for your consideration.