Add support for t-strings in the stdlib logging library

[pR0Ps]

Feature or enhancement

Proposal:

Rationale

Deferring the evaluation of log messages by passing a message template and args is recommended to avoid formatting messages until they're actually emitted, as well as allow handlers to access the unformatted args.

Unfortunately, since the c-style % formatting is less capable (and less-loved) than f-strings and str.format(), many developers pass a single pre-formatted string to the logging calls instead of using a %-style template and arguments to format into it. This prevents the deferring of the formatting until output time, as well as doesn't allow the arguments to be set on the log record for any of the handlers to use.

By extending the stdlib logging library to handle t-strings natively, we make it easier to properly use all the features of the logging system without sacrificing the convenience that led many developers to use f-strings instead.

Proposal

Add support for t-strings to the LogRecord class so that instead of calling logger.info(f"key: {value}"), logger.info(t"key: {value}") can be used as a (mostly) drop-in replacement. This would allow deferring the actual formatting of the string until the getMessage() is called on the LogRecord, as well as allow the arguments to be extracted from the t-string so they can be set as LogRecord.args.

This style of logging is also called out as possible and useful in the examples section of PEP-750, but its implementation currently requires a custom logging.Formatter, making it less likely it will be generally used. As in the PEP-750 examples, the t-strings would be formatted in the same way as an f-string since that would be the natural expectation of how a t-string would be formatted into a log message. This would also allow a simple upgrade (in most cases) from f-string to t-string in existing logging calls.

Compatibility

This would be a backwards-compatible feature since any new functionality can be gated behind isinstance(..., Template) checks so that the new logic only applies when a t-string is used.

Example

import logging

# define a handler to demo being able to access the logging args
class MyStreamHandler(logging.StreamHandler):
    def emit(self, record):
        super().emit(record)
        print(f"Emitted `{record.getMessage()}` with args: {record.args}")

logging.basicConfig(level=logging.INFO, handlers=[MyStreamHandler()])

test1 = "A"
test2 = "B"

logger.info(f"{test1=}, {test2}")  # f-string - interpolated immediately 
logger.info(t"{test1=}, {test2}")  # t-string - not interpolated until the message is emitted 

Would print:

INFO:root:test1='A', B
Emitted `test1='A', B` with args: ()
INFO:root:test1='A', B
Emitted `test1='A', B` with args: {'test1': 'A', 'test2': 'B'}

Proof of concept

To demonstrate this proposal, I've published tstringlogger on PyPI that patches this functionality onto the stdlib logging library. I have also submitted a PR that demonstrates the feature and can be used as a starting point for an implementation, should this feature be accepted.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

https://discuss.python.org/t/add-support-for-t-strings-in-the-stdlib-logging-library/92776

Linked PRs

• GH-134394: Add native support for t-strings in the stdlib logging library #134395

[pR0Ps]

cc @lysnikolaou

[vsajip]

This is a minor feature

Not so sure. It's easy enough to implement, so perhaps minor in that sense, but I wonder if implementing this as default behavior would tie people's hands in some way. I think t-strings are still too new a feature, and that all the ways of using them are not immediately clear. I would prefer a topic to be opened on discuss.python.org for this.

[sobolevn]

I agree with @vsajip, we need to learn more about the use-case first. I am pretty sure that people might want to provide some extra filtration / context for t-strings. That's the whole point of the PEP. And I think that we might expose some API that provides this new approach for formattings things.

Let's start with a discussion.

[pR0Ps]

I have submitted a thread on discuss.python.org here to discuss this and linked it in the issue.

[mikeshardmind]

This won't play well with existing logging apis such as logging filters. Everything currently expecting a string would now need to handle a the resulting template object from t-string literals, which has an incompatible API with strings

The motivation also ignores that there's already a way to use brace formatting in logging by setting the style of a logger's formatter to { and setting the logrecordfactory, and that the documentation of that even calls out the backward compatibility concerns of doing this kind of change by default.

[gpshead]

I think use of t-strings in logging is important, but we shouldn't rush. I expect some exploration on this topic via PyPI libraries on top of 3.14.

Structured logging is very much a popular thing these days, t-strings provide a structure, many modern logging systems also want the structured input to the log statement when emitting log records such that it can be queried based on structural elements instead of formatted string matching & parsing.