On Thu, Jan 28, 2010 at 11:01 AM, <s...@pobox.com> wrote:
>
> pje> If you look for a local variable in each frame containing a format
> pje> string, let's say __trace__, you could apply that format string to
> pje> a locals+globals dictionary for the frame, in place of dumping all
> pje> the locals by default....
>
> I commented on the blog post before noticing all the replies here. I'll
> embellish that suggestion by suggesting that instance attributes can be as
> valuable when debugging instance methods. Perhaps __trace_self__ (or
> similar) could be fed from self.__dict__ if it exists?
>
It seems reasonable to special case the variable named "self". You might
also want other hooks. For instance in weberror we take a convention from
Zope of looking or __traceback_supplement__, which is a factory for an
object that informs the traceback (a factory so you don't have to actually
instantiate it until there's an error). I then extended its protocol a bit,
and use it for putting request information into the traceback. I can
imagine two lighter ways to do this. One is something like:
__traceback_inspect__ = ['self', 'request']
which indicates those two local variables should be inspected. Another
might be some magic method on the request object. Of course if
repr(request) is sufficient then you are golden. But it almost certainly
isn't sufficient. There's usually key objects that deserve special
attention in the case of an error, but which you don't want to flood the
output just because you happen to print their repr. (With WebOb actually
str(request) would be quite good, while repr(request) would be too brief.)
To echo Guido, in my own traceback extensions I have at least a couple
levels of try:except: around anything fancy. repr() definitely fails.
Unicode errors happen at a lot of different levels (repr() returning
unicode, for example). And everything you do may break simply by an error
in the code, and you still shouldn't lose at least the old traceback, so
putting one big try:except:traceback.print_exc() around your code is also
appropriate. Well... not quite appropriate because that would show the
exception in the traceback machinery. Instead you should save exc_info and
show both tracebacks.
Given the amount of data involved you also don't want the traceback to
become too hard to read for simple bugs. What is really useful for an
unattended process that occasionally fails with unexpected input, may be
excessive for development; either it has to be easy to switch on and off, or
there needs to be some compromise. In HTML it's easy to make a compromise
(put in a little Javascript to hide the extended detail until asked for, for
instance). Of course, in some contexts (an email, a web page) the stuff at
the top is most visible, and a great place for an abbreviated view, while in
other contexts (mostly at a console) the bottom is easiest.
Oh, and you even should consider: will you get a unicode error on output?
I'd actually suggest returning a unicode subclass that won't ever emit
UnicodeEncodeError when it is converted to a str or bytes. Correctness at
that stage is not as important as not losing the exception.
So... a few suggestions.
--
Ian Bicking | http://blog.ianbicking.org
_______________________________________________
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
