[Python-ideas] Efficient debug logging

[Barry Scott]

> On 15 Feb 2017, at 21:06, Abe Dillon <abedillon at gmail.com> wrote:
> 
> On 15.02.2017, 20:39 Kyle Lahnakoski wrote:
> 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).
> 
> Again, isn't that what Filters are for? I mean the documentation says:
> Filters can be used by Handlers and Loggers for more sophisticated filtering than is provided by levels. 

Filters could be used instead of a wrapper around the outside of logger.debug() as far as I can see.
Buts it not clear that this is better then what I and others seem to do that is wrap the call to logger.debug().

However the use case I’m looking to improve is to avoid the cost of creating the arguments to the logger call.

> 
>  On 15.02.2017, 20:39 Kyle Lahnakoski wrote:
> 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"
> 
> That sounds interesting. It sounds a lot like a future. I like that it's a generalization of the problem (lazy expression evaluation) instead of a narrow problem (conditionally logging expensive messages) that is otherwise easily addressed by custom logic.

Agreed if this specific use case is solved by a general mechanism that is fantastic.

> 
> On 16.02.2017, 5:47 Barry Scott wrote:
> __repr__ is interesting however.
> 
> Typically I describe in a string why the value is being logged. That means
> that the object is always a string. I cannot recall using debugLog( obj )
> in production.
> 
> Loggers can handle that, though. You can easily write:
> 
> >>> log.debug("log description: val_1=%r, val_2=%s", 3.14, 100)
> 
> Instead of
> 
> >>> log.debug("log description: val_1=%r, val_2=%s" % (3.14, 100))
> 
> The former won't construct the full message if the log level is higher than debug. It won't repr 3.14 or stringify 100.

Indeed, but it did not stop them all being passed in. And if 3.14 is replaced with calculatePi( places=10000 ) there is no saving.
The lambda trick is the best short circuit so far.

> you can wrap functions in an object that only evaluates them when __repr__ and/or __str__ is called. It doesn't save you much time, because now you're writing a custom class instead of a custom function, I suppose.
> 

Barry


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