On Fri, Jan 29, 2010 at 08:02:58PM -0500, P.J. Eby wrote: > At 01:24 AM 1/30/2010 +0100, Ludvig Ericson wrote: > >> On 28 jan 2010, at 22:47, P.J. Eby wrote: >> >> > At 07:47 PM 1/28/2010 +0100, Benjamin Schweizer wrote: >> >> >> >> I like the idea of configuring the list of variables with using a >> >> convention like __trace__, though this requires me to specify what >> >> variables cause an exception and that would be hard? >> > >> > The idea is that you simply use __trace__ to format the local >> variables for that frame. In other words, the programmer specifies >> what they want to see at that point in the traceback, by setting a >> variable in their code. If there's a __trace__ variable in the frame >> locals at that point in the traceback, simply format the traceback >> locals+globals using that string's .safe_format() method. >> >> This seems very naïve to me. It makes the code ten times as hard to >> maintain; adding or removing a *local variable* suddenly means you >> have to check what __trace__ or whatever refers to. > > You lost me; the purpose of a __trace__ is to show *context* -- the > primary *purpose* of the code at that point in the call stack. You > don't put every variable in it, as that would go directly against the > purpose. > > That is, it's intended to *reduce* information overload, not increase > it. If you're putting more than 2 variables in a given __trace__ you're > probably doing something wrong.
Ok, so how do we get things done? Is there already an implementation of __trace__ around? I've not yet looked at Kristjáns traceback2.py; may be it's superior. I've tried to implement the variable dump feature with few changes, keeping the original structure of traceback.py as it was. It's finished and compatible, but it requires some testing. From here, I think we could 1) keep traceback.py as it was 2) add my non-invasive patch 3) further improve traceback.py to implement __trace__ 4) switch to Kristján's traceback2.py 5) improve Kristján's traceback2.py even further. Greetings -- http://benjamin-schweizer.de/contact _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
