Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > PyWart: Exception error paths far too verbose

Reply
Thread Tools

PyWart: Exception error paths far too verbose

 
 
Rick Johnson
Guest
Posts: n/a
 
      01-16-2013

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\e cho.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
 
Reply With Quote
 
 
 
 
donarb
Guest
Posts: n/a
 
      01-16-2013
Done

https://github.com/erikrose/tracefront

This module displays traces with shortened paths, and will even prepend your editor of choice and line number to the path, making a shortcut to jumping to the source in error via copy/paste.
 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      01-16-2013
On Wed, Jan 16, 2013 at 7:31 PM, donarb <(E-Mail Removed)> wrote:
> Done
>
> https://github.com/erikrose/tracefront
>
> This module displays traces with shortened paths, and will even prepend your editor of choice and line number to the path, making a shortcut to jumping to the source in error via copy/paste.


Are you aware of the extreme dangers inherent in the use of time machines?

ChrisA
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      01-16-2013
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\e cho.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

 
Reply With Quote
 
Michael Torrie
Guest
Posts: n/a
 
      01-16-2013
On 01/15/2013 10:59 PM, Rick Johnson wrote:
> Why do i need to see "C:\users\user\documents\python\lib" EVERY time?


You're thinking about things from a very windows-centric point of view.

There are many cases where as a developer I need to see the full paths.
My modules are not always going to be in a common subfolder. Django
apps, for example, live in an arbitrary folder, in my case,
/var/www/apps on my web server. Sometimes they live in my home projects
folder. Django itself lives partly in /usr/lib/python2.7/site-packages
and partly in /usr/share/django. Granted most of my errors are going to
happen in my own code, which is in /var/www/apps/blah. But occasionally
I might uncover a django bug (less likely of course). Seeing the full
path is essential for me. As well, runtime errors get logged as the
system is serving, and they could come from any of my apps, depending on
how bad a programmer I am.

Finally, in an ideal world, all runtime errors should be trapped by the
program. The end user should never see them. Sure in my django apps
things go south from time to time. But typically the trace gets logged
to a file, and the end user sees a 503 error, and gives me a call.
Ideally of course, the code should recover gracefully and let the user
do most of what he wants.

Traces are for developers, not users.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      01-16-2013
On Tue, 15 Jan 2013 21:59:42 -0800, 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.


What personal library folder?


> For example. Say your personal library exists in:
>
> C:\users\user\documents\python\lib



I have Python scripts in my home directory:

/home/steve/

and in a python subdirectory:

/home/steve/python

and in site packages:

/usr/lib/python2.4/site-packages/
/usr/local/lib/python2.5/site-packages/
/usr/local/lib/python2.6/site-packages/
/usr/local/lib/python2.7/site-packages/
/usr/local/lib/python3.2/site-packages/
/usr/local/lib/python3.3/site-packages/

and to my shame on my Desktop, the bane of my life (can't live with it,
can't live without it):

/home/steve/Desktop

and in my scripts directory:

/home/steve/scripts


So, which of those directories is my personal library?


> Since all directories *BELOW* the directory that holds your personal
> Python library are /superfluous/ when posting exceptions to stderr,


I think you mean "above". The root is at the top of the directory tree,
not the bottom.

/a/b/c

c is below b, which is below a.



> 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



There is a difference between "less words to read" and "more helpful".
Professional programmers do not have the luxury of only working in their
comfortable, personal computer. Often they are called in to fix a problem
with other people's programs: customers and clients. It would be a real
PITA to be working on an unfamiliar program on an unfamiliar system and
be faced with a error message like that.

*Especially* if you then search for a file reverb.py and get results like:

C:\Documents\python\sound\effects\reverb.py
C:\users\george\My Documents\sound\effects\reverb.py
C:\users\susan\programming\python\lib\sound\effect s\reverb.py
E:\Temp\sound\effects\reverb.py
F:\Development\python\lib\music\sound\effects\reve rb.py
G:\app-dev\sound\effects\reverb.py


Printing the full path is harmless when you already know which directory
the file is, because you can skim over the path and just pay attention to
the file name. If you don't know which directory the file is in, printing
the full path is essential.

On the other hand, abbreviating the path gains you practically nothing
when you know where the file is, and costs you a lot when you don't.


--
Steven
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      01-16-2013
On Wednesday, January 16, 2013 8:20:12 AM UTC-6, Michael Torrie wrote:
> On 01/15/2013 10:59 PM, Rick Johnson wrote:
> > Why do i need to see "C:\users\user\documents\python\lib" EVERY time?

>
> You're thinking about things from a very windows-centric point of view.


How are file paths or directories a windows _only_ point of view. Last time i checked, the other "big two" supported such features.

> There are many cases where as a developer I need to see the full paths.


Yes i agree, but not if those files exist in you dev library.

> My modules are not always going to be in a common subfolder.


Well they should be, however, there are a few valid exceptions.

> Django
> apps, for example, live in an arbitrary folder, in my case,
> /var/www/apps on my web server.


And a web server would be a valid exception -- granted that the web sever is NOT your actual library folder, if it were the path could be shortened.

> Sometimes they live in my home projects
> folder. Django itself lives partly in /usr/lib/python2.7/site-packages
> and partly in /usr/share/django. Granted most of my errors are going to
> happen in my own code, which is in /var/www/apps/blah. But occasionally
> I might uncover a django bug (less likely of course). Seeing the full
> path is essential for me.


And under my plan you WILL see the whole path _IF_ the django folder is NOT your "registered"[1] lib folder.

> As well, runtime errors get logged as the
> system is serving, and they could come from any of my apps, depending on
> how bad a programmer I am.
>
> Finally, in an ideal world, all runtime errors should be trapped by the
> program. The end user should never see them.


Who said anything about end users? My comments are for developer ears only.

> Traces are for developers, not users.


This comment ignores the main point, but i agree.

[1] Whether a dev must register a lib folder or use a predetermined folder is yet to be decided.
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      01-16-2013
On Wednesday, January 16, 2013 8:20:12 AM UTC-6, Michael Torrie wrote:
> On 01/15/2013 10:59 PM, Rick Johnson wrote:
> > Why do i need to see "C:\users\user\documents\python\lib" EVERY time?

>
> You're thinking about things from a very windows-centric point of view.


How are file paths or directories a windows _only_ point of view. Last time i checked, the other "big two" supported such features.

> There are many cases where as a developer I need to see the full paths.


Yes i agree, but not if those files exist in you dev library.

> My modules are not always going to be in a common subfolder.


Well they should be, however, there are a few valid exceptions.

> Django
> apps, for example, live in an arbitrary folder, in my case,
> /var/www/apps on my web server.


And a web server would be a valid exception -- granted that the web sever is NOT your actual library folder, if it were the path could be shortened.

> Sometimes they live in my home projects
> folder. Django itself lives partly in /usr/lib/python2.7/site-packages
> and partly in /usr/share/django. Granted most of my errors are going to
> happen in my own code, which is in /var/www/apps/blah. But occasionally
> I might uncover a django bug (less likely of course). Seeing the full
> path is essential for me.


And under my plan you WILL see the whole path _IF_ the django folder is NOT your "registered"[1] lib folder.

> As well, runtime errors get logged as the
> system is serving, and they could come from any of my apps, depending on
> how bad a programmer I am.
>
> Finally, in an ideal world, all runtime errors should be trapped by the
> program. The end user should never see them.


Who said anything about end users? My comments are for developer ears only.

> Traces are for developers, not users.


This comment ignores the main point, but i agree.

[1] Whether a dev must register a lib folder or use a predetermined folder is yet to be decided.
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      01-16-2013
On Wednesday, January 16, 2013 3:53:55 AM UTC-6, Terry Reedy wrote:

> 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.


Your comment is too ambiguous for me to comprehend... Are you referring to the case where devs keep python modules and scripts in /many/ places on their disc, or something else?

> Are you are aware of
> '''
> sys.excepthook(type, value, traceback)
>
> This function prints out a given traceback and exception to sys.stderr.
>
> [...]
>
> This is how some apps and environments customize exception reporting
> (and logging). I believe some people also put a replacement in their
> site module.



I'll check it out. If the path can be trimmed there, then the problem is solved for me, but what about everyone else?

> 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.


If i do i will post it. First i need to respond to someone who always needsme to explain every detail because he has trouble comprehending even the simplest of ideas. *cough*even*cough*prano

> 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!)


IDLE already has a build in command from the context menu called "go to file/line" that will parse any right-clicked line for file paths and line numbers, then, open that file in a new IDLE editor instance and adjust the viewso you can see the lineno in question (typical IDE stuff)... but most devsprefer to use IDEs with less bugs asinine interfaces
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      01-16-2013
On Wednesday, January 16, 2013 3:53:55 AM UTC-6, Terry Reedy wrote:

> 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.


Your comment is too ambiguous for me to comprehend... Are you referring to the case where devs keep python modules and scripts in /many/ places on their disc, or something else?

> Are you are aware of
> '''
> sys.excepthook(type, value, traceback)
>
> This function prints out a given traceback and exception to sys.stderr.
>
> [...]
>
> This is how some apps and environments customize exception reporting
> (and logging). I believe some people also put a replacement in their
> site module.



I'll check it out. If the path can be trimmed there, then the problem is solved for me, but what about everyone else?

> 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.


If i do i will post it. First i need to respond to someone who always needsme to explain every detail because he has trouble comprehending even the simplest of ideas. *cough*even*cough*prano

> 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!)


IDLE already has a build in command from the context menu called "go to file/line" that will parse any right-clicked line for file paths and line numbers, then, open that file in a new IDLE editor instance and adjust the viewso you can see the lineno in question (typical IDE stuff)... but most devsprefer to use IDEs with less bugs asinine interfaces
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
WiMAX in 2010: Too little, too late? How fast, how far, how much? Obaid MCSA 0 10-19-2009 12:12 PM
WiMAX in 2010: Too little, too late? How fast, how far, how much? Obaid MCAD 0 10-19-2009 12:12 PM
ToolTipText pop up far far away from mouse pointer RC Java 2 01-08-2008 12:54 AM
Taking table-less CSS design far too far Andy Dingley HTML 45 06-11-2006 07:14 PM
Convert between Windows style paths and POSIX style paths Noah Python 5 07-11-2003 09:25 PM



Advertisments