Is there a way to disable message formatting ?

[gjeusel]

Hi Delgan !

I was wondering if there was a way to disable the message formatting with the args/kwargs ?

from loguru import logger

kwargs = {"a": 1, "b": 2}
logger.info(f"Is this going to be alright ? {kwargs}", additional_infos=kwargs)

Traceback:

Traceback (most recent call last):
  File "/tmp/test.py", line 4, in <module>
    logger.info(f"Is this going to be alright ? {kwargs}", additional_infos=kwargs)
  File "/Users/gjeusel/miniconda3/envs/greenpandas/lib/python3.6/site-packages/loguru/_logger.py", line 1971, in info
    __self._log("INFO", None, False, __self._options, __message, args, kwargs)
  File "/Users/gjeusel/miniconda3/envs/greenpandas/lib/python3.6/site-packages/loguru/_logger.py", line 1948, in _log
    log_record["message"] = message.format(*args, **kwargs)
KeyError: "'a'"

Is it a feature you would be inclined in adding ?
Maybe parametrized by an environment variable or via logger.configure ?

Cordially !

[Delgan]

Hi!

Well, you can disable formatting by not providing any argument. If you want some arguments to be added to the extra dict, you can use bind() instead:

logger.bind(additional_infos=kwargs).info(f"Is this going to be alright ? {kwargs}")

Another possiblity is simply to not use f-strings:

logger.info("Is it going to be alright? {additional_infos}", additional_infos=kwargs)

I agree that this may not be the most convenient, since it implies always having to think about that particular case. Especially as auto-formatting is not very useful anymore now that f-strings are widely used.

I'm not a big fan of adding more and more configuration options because it makes the code and the api more complex. But maybe I need to reconsider my position.

[gjeusel]

Thx for your answer !
Indeed, using the bind() to fill up extras might be a solution.

I understand your aversion of adding more configuration. Let's wait and see if this feature is of interest to some more people ?

[Delgan]

I may have some ideas to allow more freedom in configuring the message formatting. I think this feature might be of interest to some people, in your case and others. But I'm not sure of anything, we'll see. I'll keep this issue open in the meantime. 👍

[kace]

Hi,

I just ran into a similar issue when using an intercept handler to collect logs from pika/pika. The library logs a dictionary at some point, which throws a KeyError exception when I add a keyword argument to the same logging function call.

Your suggestion to use bind() works, but I figured I'd add my use case here anyways.

Thanks for your hard work on Loguru!

[Delgan]

Thanks @kace for the additional use case, it's very helpful to have this kind of example while thinking about a solution.

I plan to propose a way to configure formatting, but I still haven't decided which one. Adding a parameter like logger.configure(autoformat=False) is obviously the easiest, but I'm afraid it opens the door to too many additional parameters. Also, I would like it to be flexible enough to implement customized alternatives like #359. Ideally, one could just patch() the logger using the existing method. But this one is currently called after formatting so it wouldn't work.

Anyway, I am still thinking about this issue. ;)

[soundstripe]

In my case, this happened to me when I combined captureWarnings() with modifying my InterceptHandler to include extra=.

import logging
import loguru
import warnings

logger = loguru.logger

class InterceptHandler(logging.Handler):
    def emit(self, record):
        # Get corresponding Loguru level if it exists
        try:
            level = logger.level(record.levelname).name
        except ValueError:
            level = record.levelno

        # Find caller from where originated the logged message
        frame, depth = logging.currentframe(), 2
        while frame.f_code.co_filename == logging.__file__:
            frame = frame.f_back
            depth += 1

        logger.opt(depth=depth, exception=record.exc_info).log(
            level, record.getMessage(), extra={'more info': 'something else'}  # this line changed from usual to include extra=
        )

logging.captureWarnings(True)
logging.getLogger('py.warnings').handlers = [InterceptHandler()]

if __name__ == '__main__':
    id_ = 23
    warnings.warn(f'problem with something of id: {id_}')

(The above results in an unexpected KeyError because warnings are automatically formatted by Python to include the raw line of code from which they were thrown).

My workaround right now is to use contextualize() instead of adding the extra() manually:

       with logger.contextualize(**{'more info': 'something else'}):  # adds the context data to logged messages here
            logger.opt(depth=depth, exception=record.exc_info).log(
                level, record.getMessage()
            )

[kace]

@soundstripe This is very similar to my use case. You can see my workaround using bind in my comment on another issue. This is especially useful if more info in your code doesn't change between logging calls.

If I remember correctly my original implementation passed the id parameter as a keyword argument to the logging call. I think the documentation mentions that any additional kwargs in this method call are automatically added to the extra's dict.