21 Using particular formatting styles throughout your application In Python 3.2, the Formatter gained a style keyword parameter which, while defaulting to % for backward com- patibility, allowed the specification of { or $ to support the formatting approaches supported by str.format() and$_{string.Template}$ . Note that this governs the formatting of logging messages for final output to logs, and is completely orthogonal to how an individual logging message is constructed. Logging calls ( debug() , info() etc.) only take positional parameters for the actual logging message itself, with keyword parameters used only for determining options for how to handle the logging call (e.g. the exc_info keyword parameter to indicate that traceback information should be logged, or the extra keyword parameter to indicate additional contextual information to be added to the log). So you cannot directly make logging calls us- ing$_{str.format()}$ or$_{string.Template}$ syntax, because internally the logging package uses %-formatting to merge the format string and the variable arguments. There would no changing this while preserving backward compatibility, since all logging calls which are out there in existing code will be using %-format strings. There have been suggestions to associate format styles with specific loggers, but that approach also runs into backward compatibility problems because any existing code could be using a given logger name and using %-formatting. For logging to work interoperably between any third-party libraries and your code, decisions about formatting need to be made at the level of the individual logging call. This opens up a couple of ways in which alternative formatting styles can be accommodated. In Python 3.2, along with the Formatter changes mentioned above, the logging package gained the ability to allow users to set their own$_{LogRecord}$ subclasses, using the$_{setLogRecordFactory()}$ function. You can use this to set your own subclass of$_{LogRecord}$ , which does the Right Thing by overriding the$_{getMessage()}$ method. The base class implementation of this method is where the$_{msg % args}$ formatting happens, and where you can substitute your alternate formatting; however, you should be careful to support all formatting styles and allow %-formatting as the default, to ensure interoperability with other code. Care should also be taken to call$_{str(self.}$ msg) , just as the base implementation does. Refer to the reference documentation on$_{setLogRecordFactory()}$ and$_{LogRecord}$ for more information. There is another, perhaps simpler way that you can use {}- and $- formatting to construct your individual log messages. You may recall (from arbitrary-object-messages) that when logging you can use an arbitrary object as a message format string, and that the logging package will call$_{str()}$ on that object to get the actual format string. Consider the following two classes: 21.2 Using custom message objects 21.1 Using LogRecord factories 32 classBraceMessage : def __init__ (self, fmt, /,*args,**kwargs): self.fmt =fmt self.args =args self.kwargs =kwargs def __str__ (self): return self.fmt.format( *self.args,**self.kwargs) classDollarMessage : def __init__ (self, fmt, /,**kwargs): self.fmt =fmt self.kwargs =kwargs def __str__ (self): from string import Template return Template( self.fmt) .substitute( **self.kwargs)