[Python-ideas] Efficient debug logging

Kyle Lahnakoski klahnakoski at mozilla.com
Tue Feb 14 21:39:27 EST 2017

On 2017-02-14 19:51, Abe Dillon wrote:
>    The point is that the cost of creating the msg argument can be very
> high.
>     At the point that logging decides to skip output it is to late to
> save the cost of creating the arg     tuple.
> This sounds like an optimization that's sufficiently rare and complex
> to warrant a custom fix or a 3rd party library.
>     Not that it is relivent for this idea bit logging's levels are too
> course for logging in complete
>     applications. The app I am working on at the moment has 20
> seperate debug categories
>     that are independently enabled.
> Holy balls! That sounds like a tortured use of log levels!

That's a funny expression.  :)

I have not got to the point of 20 debug categories in a single file, but
I easily have 20+ debug categories in an application.  I previously
suggested wrapping the expensiveFunction in a lambda, but that is not
what I do.  I prefer using explicit logging switches:

____if DEBUG_FEATURE_A:   
________debugLog(msg, expensiveFunction() )
____if DEBUG_FEATURE_B:   
________debugLog(msg2, expensiveFunction2() )

The benefit is clarity at the expense of more lines, while still
avoiding the expensiveFunction() when I can. Using switches result in a
smaller log file, because logging is focused on the feature, plus, these
switches can still be dynamically set from outside the module.

Log "levels" never made sense to me; how can a single dimension be
useful substitute for a number of binary switches?  With log "levels",
you either don't have enough logging, or you drown in too much logging
(or you manage a number of loggers, which is worse than logging switches).

But to stick to the theme of language features:  I believe there is a
previous thread that touches on a solution to the original posters
problem:  "Alternative to PEP 532: delayed evaluation of expressions"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170214/4a3bb38d/attachment-0001.html>

More information about the Python-ideas mailing list