[Python-ideas] Efficient debug logging

Abe Dillon abedillon at gmail.com
Wed Feb 15 16:06:14 EST 2017

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.

 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.

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.

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.

On Wed, Feb 15, 2017 at 10:46 AM, Sven R. Kunze <srkunze at mail.de> wrote:

> On 15.02.2017 12:55, Barry Scott wrote:
>> The lazy eval sound like a generator.
> Exactly my thought.
> Sven
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170215/13e674d1/attachment.html>

More information about the Python-ideas mailing list