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 andstr.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 theLogRecord class so that instead of callinglogger.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 thegetMessage() is called on theLogRecord, as well as allow the arguments to be extracted from the t-string so they can be set asLogRecord.args.

This style of logging is also called out as possible and useful in the examples section ofPEP-750, but its implementation currently requires a customlogging.Formatter, making it less likely it will be generally used. As in thePEP-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 behindisinstance(..., Template) checks so that the new logic only applies when a t-string is used.

Example

importlogging# define a handler to demo being able to access the logging argsclassMyStreamHandler(logging.StreamHandler):defemit(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 immediatelylogger.info(t"{test1=}, {test2}")# t-string - not interpolated until the message is emitted

Would print:

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

Proof of concept

To demonstrate this proposal, I've publishedtstringlogger onPyPI 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