<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 14, 2017 at 3:55 PM, Barry <span dir="ltr"><<a href="mailto:barry@barrys-emacs.org" target="_blank">barry@barrys-emacs.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="gmail-"><div><br></div></span><div>The point is that the cost of creating the msg argument can be very high.</div><div><br></div><div>At the point that logging decides to skip output it is to late to save the cost of creating the arg tuple.<br></div></div></blockquote><div><br></div><div>Awhile back I was playing with some code for the purpose of adding debug logs "after the fact":<br></div><div><br></div><div><a href="https://github.com/anthonyrisinger/retrospect/blob/master/README.rst">https://github.com/anthonyrisinger/retrospect/blob/master/README.rst</a><br></div><div><br></div><div>I'm not trying to plug it (It's POC, broken, and Python 2) but maybe there is some value because I was trying to solve a similar problem of fast and easy debugging and logs.</div><div><br></div><div>The idea here is we target a function for "retrospection" by replacing it's code object with a modified variant that implements call outs at different points. Such interesting points might be "on symbol table changes" (new vars) or "on identifier rebinding" (updating vars) or "on line changes" or even "every single tick" to inspect TOS.</div><div><br></div><div>I like this approach of latching onto the function/code object directly because it does not require a wrapper, but it can have be tricky with decorators depending on what the decorator does with the function it receives (we need access to the function object to replace it's __code__).</div><div><br></div><div>I don't much like writing logs. They are verbose in code and almost always either much more or less than I need to deal with the problem at hand, and it's not always clear what's important ahead-of-time. With all the implementation details in play, you might end up wrapping code in context managers and whatnot for the sole purpose of logging. Or you have to jump thru hoops to get the exact info you need using many log levels or flags. I think having a way to target functions for real time introspection, then perfectly disable it, could allow for interesting solution to large, cross-cutting concerns like application logging.</div><div><br></div><div>Is there any interest in this? Say a new function method like fun.trace(vars=[a,b,c])? Is there already a solution or past discussion on this topic?</div><div><br></div><div>Thanks,</div><div><br></div><div>-- </div><div><br></div><div>C Anthony</div></div>
</div></div>