Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a 'length' argument to the 'add' function supporting "max_length" #1224

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

daniel347x
Copy link

This was a trivial change but of massive value for me to be able to simply pass a flag to the logger.add() function controlling the maximum line length in stack trace diagnostics.

The limit of 128 characters is too small, and the only reason I use Loguru is for this functionality, so I'm surprised it's not in place already given how trivial a change it is.

I do not object to the few seconds it takes to scroll to the right to see all variable values - not cut off by three dots - if it means saving hours or days of debugging time.

Note: The code uses the same approach as the existing design pattern of tying the default to a user-settable environment variable. Additionally, the default of 128 remains the same.

I also noticed the convention of single-word arguments to add, so I chose "length" as the name of this argument.

@Delgan
Copy link
Owner

Delgan commented Nov 11, 2024

Hi @daniel347x.

Thank you for your interest in contributing to Loguru.

Getting back at your comment at #173 (comment), it still seems natural to define a limit to the maximum length of the values displayed in the traceback. Since any arbitrary object can end up being printed, this avoids flooding if a long text or verbose dictionary happens to be logged.
Displaying values is convenient for a quick overview in the event of an error during development, but it cannot replace the use of a debugger.

I agree it seems quite straightforward to simply add a new length argument to logger.add(). However, I'm not necessarily in favor of such an approach, as the add() API is already quite complex and I'd like to avoid adding too many new options.

This is why for more advanced cases like yours, it's still possible to fully adapt exception formatting using a custom format function, as demonstrated in the above mentioned ticket.
Given that this is not an very common use case, it seems to be an acceptable solution, which doesn't require any changes to Loguru.

That being said, I understand it can frustrating not to be able to easily adjust the width limit.

Your point makes me realize that it might be interesting to deprecate existing backtrace and diagnose arguments in favor of a new argument dedicated to exception formatting (and which could also deal with max length). This is all the more relevant as there are other formatter (such as the rich one) that could benefit from easier interfacing with Loguru logger. It was actually already suggested in #86.

Rough idea:

logger.add(sys.stderr, format="{time} {message}", traceback=lambda exc: logger.traceback(exc, width=999))

Nothing concrete yet. But I think there's merit in considering a more generic approach, rather than a new length argument.

If it's acceptable to you in the short term, however, I'd be happy to support a new environment variable to set the maximum length of the current traceback. I'd prefer something like LOGURU_TRACEBACK_WIDTH. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants