Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder2.hal-mli.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: PyWart: Exception error paths far too verbose
Date: Wed, 16 Jan 2013 04:53:55 -0500
References: <e887a93f-ea32-442c-9673-4da892b9f37e@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
In-Reply-To: <e887a93f-ea32-442c-9673-4da892b9f37e@googlegroups.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.565.1358330072.2939.python-list@python.org>
Lines: 80
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:36889

On 1/16/2013 12:59 AM, Rick Johnson wrote:
>
> Python needs to trim the path to the source file from which the
> exception was caught and only display the relative path starting from
> your personal library folder.
>
> For example. Say your personal library exists in:
>
> C:\users\user\documents\python\lib
>
> ...then there is no need to post THAT portion of the path EVERY
> STINKING TIME! For instance, let's say a script at:
>
> C:\users\user\documents\python\lib\sound\effects\echo.py
>
> ...throws an error. What will we see?
>
> Traceback (most recent call last): File
> "C:\users\user\documents\python\lib\sound\effects\echo.py", line N,
> in BLAH
>
> Why do i need to see "C:\users\user\documents\python\lib" EVERY
> time?
>
> Since all directories *BELOW* the directory that holds your personal
> Python library are /superfluous/ when posting exceptions to stderr,
> trimming this bloat can really help to make exception messages easier
> to read.
>
> Traceback (most recent call last): File
> "...\sound\effects\reverb.py", line XXX, in YYY

I agree with the complaint and you may have the germ of a good idea. The 
problem is that for some tracebacks, paths jump all over the place 
rather than having a common prefix. Dealing with this might require 
preprocessing the entire traceback before iterating and printing each item.

Are you are aware of
'''
sys.excepthook(type, value, traceback)

     This function prints out a given traceback and exception to sys.stderr.

     When an exception is raised and uncaught, the interpreter calls 
sys.excepthook with three arguments, the exception class, exception 
instance, and a traceback object. In an interactive session this happens 
just before control is returned to the prompt; in a Python program this 
happens just before the program exits. The handling of such top-level 
exceptions can be customized by assigning another three-argument 
function to sys.excepthook.
'''
This is how some apps and environments customize exception reporting 
(and logging). I believe some people also put a replacement in their 
site module.

 >>> import sys; sys.excepthook
<built-in function excepthook>

I expect the default, excepthook, is something like

def excepthook(typ, value, traceback):
     print('Traceback (most recent call last):', file=sys.stderr)
     for item in traceback:
         print(format_tb_item(item), file=sys.stderr)
     print('{}: {}'.format(typ.__name__, value), file=sys.stderr)

(or the equivalent with sys.stderr.write)

What you want to change is format_tb_item (possibly, as I said, after 
scanning traceback before the print loop). If you come up with something 
nice, I would like to see it.

The only thing special that IDLE does now is to color the text red. I 
should sometime see how that is done. (Being able to doubleclick on an 
item and have IDLE open an edit window at the specified line would be 
really nice!)

-- 
Terry Jan Reedy