[issue14031] logging module cannot format str.format log messages

[kespindler]

kespindler added the comment:

I definitely do recognize that important case. I think the proper solution,
however, to that is make a very clear warning in the documentation that
changing the style might affect the logging of 3rd party tools. Those users
would probably have to use the % style formatting, which continues to work
exactly as always. I'd also note, this issue is largely related to the
`basicConfig` command. Anybody using significant 3rd party tools is likely
using a more complicated solution. In that case, this patch gives them the
flexibility to specify both LogRecords and the Formatter in whichever way
they desire.

The problem with leaving the behavior as is is that currently the style
keyword is effectively useless and grossly misleading to users.

Furthermore, the documentation makes reference to the ability to use new
style formats. From Logging HOWTO:

> As you can see, merging of variable data into the event description
message uses the old, %-style of string formatting. This is for backwards
compatibility: the logging package pre-dates newer formatting options such
as str.format() and string.Template. **These newer formatting options are
supported, but exploring them is outside the scope of this tutorial.**

This interpretation is the most logical interpretation of the style
keyword. Again, the format string is used once and is of comparative little
consequence - there's no real need for changing its format. Log messages
are written many, many times, and so it makes sense to allow the user to
write them in the modern format.

If the behavior really cannot be changed, this patch does provide
subclasses to LogRecord that give the desired behavior. Technically these
can be used independently of the style keyword.

On Mon, Jan 13, 2014 at 11:48 AM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray added the comment:
>
> The reason is simple: in the general case you do not control all of the
> statements that produce log messages.  Some of them come from 3rd party
> library code.
>
> Perhaps the documentation needs to be clarified on this point, and
> document the technique mentioned in the blog post Vinay linked to?  Or
> perhaps some pre-built wrappers can be provided in 3.5?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue14031>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14031>
_______________________________________