On Tue, Dec 25, 2012 at 10:42 PM, Rene Nejsum <rene@stranden.com> wrote:
Add's 5-10% extra code lines, whereas if we could do:
log.debug( bla. bla )
at the same cost would save a lot of lines.
Right, that's where the lazy evaluation API idea comes in where there's no choice except to do the expensive calculation in process and you want to factor out the logging level check, it's possible to replace it with 7 characters embedded in the call: debug_lazy(lambda: bla. bla.) You can also do much more sophisticated things with the logging event handling system that only trigger if an event passes the initial priority level check and gets submitted to the rest of the logging machinery. There's no magic wand we can wave to say "evaluate this immediately sometimes, but lazily other times based on some unknown global state". An API has to choose one or the other. The standard logging APIs chooses do lazy evaluation of formatting calls, but eager evaluation of the interpolated values in order to speed up the typical case of readily accessible data - that's why the active level query API is exposed. Another logging API could certainly make the other choice, adapting to the standard APIs via the level query API. I don't know if such an alternative API exists - my rule of thumb for logging calls is if something is too expensive to calculate all the time, find a way to instead pass the necessary pieces for external reconstruction to a lazy formatting call rather than making a given level of logging prohibitively expensive. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia