[Feature Request] `with`-block timer notation

[DeflateAwning]

I am requesting an easy way to use a with-block (context block) to time the execution of a piece of code, directly with loguru.

For example, I want to be able to run this:

from loguru import logger

def demo():
    with logger.timer_block("Running function_a and function_b"):
        a_result = function_a() # takes about 10 seconds
        b_result = function_b() # takes about 15 seconds

demo()

The result of running demo() would be an INFO-level log message, which appears to be coming from the demo() function, which says "Running function_a and function_b took 0h 0m 25.120s." (or something to that effect).

The proposed logger.timer_block(...) function would have the following argments:

• Arg 0 (mandatory): description - a description of the code being run
• Arg 1: log level
• Maybe others?

Currently, I end up writing code that looks a lot like this to accomplish the same thing, but with much higher code repetition. I'd be happy if I never had to write this code again.

from loguru import logger
from datetime import datetime

def demo():
    start_time = datetime.utcnow()
    a_result = function_a() # takes about 10 seconds
    b_result = function_b() # takes about 15 seconds
    logger.info(f"Running function_a and function_b took {datetime.utcnow() - start_time}.")

demo()

[Delgan]

Hi @DeflateAwning.

Thanks for the suggestion but I consider such feature to be out-of-scope for the Loguru project.

See related discussions:

• https://github.com/Delgan/loguru/issues/363
• https://github.com/Delgan/loguru/issues/539
• https://github.com/Delgan/loguru/issues/65

Measuring elapsed time is a functionality completely orthogonal to logging. Therefore, I don't think such feature should be part of Loguru as a built-in.

[DeflateAwning]

Measuring elapsed time is a functionality completely orthogonal to logging.

Can you explain this opinion more? One of the most common things I see in logs of both my own projects, and of other people's projects, is log messages indicating these sorts of elapsed times of actions. They are one of the most important pieces to be able to pull out of logs and monitor in log outputs.

While these sorts of snippets can be added to projects' internal libraries/helper function collections, having them available right from the start in my logging library of choice is what makes this library so powerful.

Curious to hear more about why you won't include these functions, even though they only add functionality, and don't at all detract from the core of what loguru is: an awesome, batteries-included logging library.

[Delgan]

I agree this would be a convenient addition, but on the other hand, I maintain the view that such feature do not belong to the core of a logging library. Such functionalities are better suited as standalone tools or can be easily implemented within user code or utility libraries.

I try to keep Loguru minimal and to focus of the logging part. It's primary role is to provide a streamlined way to log messages. However, the decision of "what" to log should remain in the hands of the developer. The only exception to this rule is logger.catch() since logging unexpected errors is easily overlooked.

We could imagine many helpers such as measuring elapsed time, tracing entry and exit of functions, and probably many others. This opens the door to too many possibilities and it will be challenging to satisfy everyone's needs (preferred units, preferred timing function, etc.).

In the end, I prefer developers to implement such specific functionalities directly within their code. This simplify the overall design and ensure flexibility for diverse use cases.

[DeflateAwning]

What do you think about an "extensions" library that can be installed via pip (e.g., pip install loguru-extensions) that adds these additional functionalities? Would you be interested in supporting it officially?

The fact that so many of us are requesting these features seems to suggest that it'd be a popular addition.

[Delgan]

I like this approach better and this is the solution I encourage. :+1:

Several libraries have been published in this way, such as loguru-mypy, pytest-loguru and loguru-config for example.

At the moment I don't have much time to develop and maintain such a library myself, but if someone is interested I could contribute and reference it in the official Loguru documentation.

[DeflateAwning]

Neat, okay! I'll plan for that then.

Can you add those three to somewhere in the official documentation?

[Delgan]

Great!

Can you add those three to somewhere in the official documentation?

They are listed on the relevant pages. :)

• Type hints page mentions loguru-mypy.
• Replacing caplog fixture from pytest library section mentions pytest-loguru.
• loguru.configure() API reference mentions loguru-config.

[codeananda]

Just want to say to you both @Delgan and @DeflateAwning that this was a lovely, civil disagreement to read.

I understand your frustration @DeflateAwning but also appreciate @Delgan's commitment to essentialism and keeping loguru (stupidly) simple. Thank you 🙏