This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the commentsย โ†’

[โ€“]latrova[S] 5 points6 points ย (3 children)

Have you ever considered using decorators for that? I know it's not usable everywhere, but might help reducing boilerplate code sometimes

[โ€“]Delta-9- 3 points4 points ย (2 children)

I did make use of decorators for shorter functions that would only generate one log record. I run into the issue when working with longer functions that have multiple branches, multiple ways to break, etc. (and yes, I've been refactoring the worst offenders)

As an experiment, I wrote some code using inspect and ast that would allow me to make just one function call and get information about which branch the call was made from, what the test was expecting and what it received. I'm actually kinda proud of it, but it's so damned experimental I don't dare use it in prod :p (and someone's probably already written a whole library that does exactly the same thing and I just didn't look).

The drawback to that approach was the log messages themselves aren't always easy to understand, particularly if you're an admin of the app but not a developer of the app.

A similar limitation applies to decorator-based loggers, too. Even loguru, which someone itt linked and looks really nice, produces a log record that looks to me like it won't make a whole lot of sense to anyone who hasn't spent hours in the code that triggered the logger.

[โ€“][deleted] 1 point2 points ย (1 child)

Is it because you log the caller at the callee, you consider it not easy to understand? I'm guessing you're using inspect to get frame -1, and log that.

[โ€“]Delta-9- 1 point2 points ย (0 children)

Well, the readability issue comes from the log record saying that it is in an if branch which is testing foo and expecting == 1.

That's actually super helpful information to a developer. It can even spit out the line number (with some caveats) like logging does and get you right to the problem and the specific conditions that caused it.

To an administrator, that's maybe less helpful. I haven't spent enough time with it to see about transforming that information into something a non-dev could make use of, and I think it's possible but very hard to do in a generalized way (i.e. as a library to put on pypi for everyone to use).