Feature: Ability to automatically add color to format strings

[rawrke]

Description 📝

Add the ability to automatically insert color variables in format strings. This would automatically put color tags around curly braces within a log message, and then render it to a color.

For instance, if the passed string to the logger is "a: {}, b: {}, c: {}", then loguru will add a preconfigured color tag to the string before sending off to a sink, like so: "a: <m>{}</m>, b: <m>{}</m>, c: <m>{}</m>". In this case, the tags <m></m> represent the color magenta.

Example 📇

NOTE: The below example does not reflect the required configuration to enable this feature. A feature flag would likely be required to preserve backwards compatibility.

import sys
from loguru import logger
import math

logger.remove()

# Enable color rendering within a message
logger = logger.opt(colors=True)

# Add a sample logger
logger.add(
    sys.stdout,
    colorize=True,
    format="<g>[{time:YYYY-MM-DD HH:mm:ss}]</g><level>[{level}]</level> {message}",
    level="DEBUG"
)

temp = {"name": "Bob", "occupation": "Builder"}
logger.debug("Houston, we have a {}", "cat")
logger.debug("Mapping: {a}, π: {pi:.4f}", a=temp, pi=math.pi)

And the output, note that the contents within the curly braces {} are automatically colored and italicized. This would be customizable based on user desires.

[rawrke]

Here is an example script that shows how to configure loguru to support this feature, with the changes implemented in #1345

import sys
from loguru import logger
import math
import re
from collections.abc import MutableMapping
import datetime

logger.remove()

# _regex_pattern = re.compile(r"(\{.*?\})")
_regex_pattern = re.compile(r"(\{[^{}]*\})(?!\})")
_regex_repl = r"<lm><i>\1</i></lm>"

def insert_color_tags(record: MutableMapping):
    record.update(message=re.sub(_regex_pattern, _regex_repl, record["message"]))

# Enable color rendering within a message
logger = logger.patch(insert_color_tags)
logger = logger.opt(colors=True)

# Add a sample logger
logger.add(
    sys.stdout,
    colorize=True,
    format="<g>[{time:YYYY-MM-DD HH:mm:ss}]</g><level>[{level}]</level> {message}",
    level="DEBUG"
)

def main():
    temp = {"name": "Bob", "occupation": "Builder"}
    d = datetime.datetime(2010, 7, 4, 12, 15, 58)

    logger.debug("Houston, <red>we</red> have a {}", "cat")
    logger.debug("Mapping: {a}, π: {pi:.4f}", a=temp, pi=math.pi)
    logger.info("{:%Y-%m-%d %H:%M:%S}", d)
    logger.info("{{double-curly has no color}}")


if __name__ == "__main__":
    main()

Output

As we can see with the output, users can now configure loguru in a way that allows them to add color to their messages with patching. This is beneficial as it requires minimal code changes and is entirely user-configured.

[Delgan]

Hey @rawrke. Thanks for the opened PR and sorry for the late answer.

I can see the appeal of deferring message formatting, as it would provide greater flexibility and allow users to adjust the formatting to their preferences.

First and foremost, it should be noted that message formatting is set to change in a future Loguru version. Notably, keyword arguments will no longer be automatically formatted within the message. They will exclusively be captured as structured context (as currently stored in the extra dict). This context will be colorized and added to the default format.

logger.info("Something happened", mapping=temp, pi=math.pi)
# Output: [22:41:04][INFO] Something happened (mapping={...}, pi=3.1416)"

I am specifying this because it seems to match one of your use case, namely highlighting certain keyword arguments in the logged message.

Regarding your suggestion, in #1345, to change the order in which patches are applied, I agree that it quite straightforward. However, as you pointed out, this is to be considered as a breaking change. Although I don't expect the impact to be broad, that's still a concern.

Additionally, some users may prefer to access the message already formatted, which would then no longer be possible. It seems that these are two fundamentally incompatible use cases. The problem we solve on one side may create another on the other side.

Finally, formatting the message after patching introduce a small inconsistency. Currently, the record dict is exposed uniformly across patches, filters, and sinks. It's always in it's "final" state, and I think such consistency is important from an API standpoint.

For these reasons, I'm not so keen to update the way patches are applied for now. That being said, I am not ruling out the idea of custom message formatting. However, this presents certain technical constraints, and I am not sure yet if it is worth the effort. This might be a good use case for PEP 750 – Template Strings.