> AFAIK, the converter attribute is only to "be set" with a function of such signature. It is not documented that it can be used and it is only used on the format time function.

What do you mean by "it is not documented"? It is documented here:

https://docs.python.org/3/library/logging.html#logging.Formatter.formatTime

See also questions on Stack Overflow relating to it:

https://stackoverflow.com/search?q=%5Bpython%5D+%5Blogging%5D+converter

Not sure what you mean by "only to be set". Obviously, it is also read *somewhere* - otherwise why would you set it?

> The only situation where this might break someone is if they inherit from formatter, substitute the formatTime function by their own implementation and rely on the function returning a time tuple. Doing that is relying on the implementation of the formatter though, as the docs explain is just something to be set.

But the converter is documented as returning a time tuple, and there conceivably exists code that relies on that. There is no reason why someone couldn't have implemented a Formatter subclass with an overridden formatTime method that assumes the converter returns a time tuple. We can't know the impact of this change in terms of the number of people/amount of software affected, but that it might break *someone's* code is IMO enough reason not to proceed with it.

> Note how you need to split the formatting of time into two different parts.

It's still a one-liner both ways in your example - just a slightly different format string. Also, note that %f doesn't give you all that much flexibility - you get six places whether you like it or not. So it's hardly something which will meet everybody's formatting requirements. So "hey, just use datefmt" won't cut it for all scenarios. Ditto for timezone display - there is a school of thought that says logs should only hold UTC time. Users can always override formatTime in their Formatter subclass to do exactly what they want - it could be a one-time thing that they can then use wherever they want.

I don't want to give the impression that I'm against *any* change - I'm not. You can see lots of changes in the logging codebase contributed by various people. A recent example in the area of logging Formatter is

https://github.com/python/cpython/pull/9703

So by all means I welcome contributions, but you might find me a bit more conservative than you would like!