Repository navigation
logging.basicConfig should support parameter formatter_class (currently instantiates hardcoded logging.Formatter) #133577
Description
Hi! 👋
Currently logging.basicConfig instantiates logging.Formatter as a formatter:
cpython/Lib/logging/__init__.py
Line 2111 in 3dfed23
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! 🙏
Activity
vsajip commentedon May 7, 2025
Well, the idea is that
basicConfigis meant for very basic configuration needs, where a hardcodedFormatterclass seems reasonable. You could always usedictConfig()to configure a specific formatter class; your suggestion wouldn't help if the formatter__init__needed anything other than the default API signature thatFormatterhas. 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 commentedon May 7, 2025
Hello @vsajip, thank for your quick reply!
@vsajip it only dictates three parameters,
CustomerFormatter.__init__would still be free to have additional key-value arguments with defaults and also use offormatter_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?Looking at how existing arguments
filemode,encoding,errorsall allow customizing the auto-createdFileHandlerI do not feel that thatlogging.basicConfigis 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 thathandlersalready allowed that to work in Python >=3.3 and the introduction ofhandlersin 3.3 could have been rejected the same way arguing that it's not basic enough forbasicConfigbut it was considered of enough value (which I support). Supporting custom formatters conveniently is the potentially last missing piece to completelogging.basicConfig, and it's a trivial fix. I don't see why it needs to be this hard to usebasicConfigwith a customer formatter and also no reasons to go fulldictConfigfor something so simple. Thanks for your consideration.gh-133577: Add parameter `formatter` to `logging.basicConfig` (GH-133578
pythongh-133577: Add parameter `formatter` to `logging.basicConfig` (p…
pythongh-133577: Add parameter `formatter` to `logging.basicConfig` (p…