[Python-ideas] Dynamic code NOPing

[Rene Nejsum]

Thanks, appreciate your answers and comments…

OT: Being brought up with a C/Java background the depth of the Python language itself still amazes me, I wonder if there is a correlation to the Python community when guys like Guido, Nick and all others takes time to answer questions in a friendly, informative and educating way….

Merry christmas to all on the list….

/Rene

On Dec 25, 2012, at 2:00 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Tue, Dec 25, 2012 at 10:42 PM, Rene Nejsum <rene at 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 at gmail.com   |   Brisbane, Australia