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
On 1-16-2013 8:45 AM Steven D'Aprano wrote:
> What personal library folder?


The single MONOLITHIC folder you SHOULD be using to contain all your personal modules and scripts! But of course you are not doing this, only professionals are consistent.

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


All of these scripts /should have/ been placed under a single directory, and i don't care where that directory is, but they should be under a single directory! ALWAYS!

And why the HELL would you place scripts on the desktop? So you can easily double click and run them? *giggles* Steven, have you heard of the new invention called a symbolic link?

http://en.wikipedia.org/wiki/Symbolic_link

> > Rick said:
> > 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.


So you understood my statement, however, you felt the need to correct me because i say "toe-mate-toe" and you say "toe-maught-toe"? interesting.

> There is a difference between "less words to read" and
> "more helpful".


Yes, and verbosity does not /always/ equal "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.


Another new invention you may not know of are "command line switches"

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


Well. Okay. Lets imagine a user "switched on" the functionality i suggest. Let's also imagine they hired you to fix some problem they are having (a stretch for most of us, i know!). Let's also /imagine/ that Python devs wouldbe dumb enough to create a command line switch to turn something on, but no way to disable it because /somehow/ this command line switch has become persistent (well, at least to your mind).

Now /imaging/ all that, let's inspect these paths:

> C:\users\george\My Documents\sound\effects\reverb.py
> C:\users\susan\programming\python\lib\sound\effect s\reverb.py


These two are invalid because you can only repair one problem at a time. And if you don't know the username of the person who's problem you are repairing, then you are not fit to repair the problem are you? Next!

> E:\Temp\sound\effects\reverb.py


Python source files should NEVER be under a temp directory, you can safely ignore this one.

> C:\Documents\python\sound\effects\reverb.py
> F:\Development\python\lib\music\sound\effects\reve rb.py
> G:\app-dev\sound\effects\reverb.py


If these last three files really exist, and are /actually/ Python scripts, i would suggest charging extra so you could have time to teach this "dev" how to intelligently store files using structure and consistency.

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


But you will, IF you keep all your python scripts under a single library folder. Actually, my suggested functionality would be a great motivator for lazies like you.

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


Actually that is wrong. Because remember, the path, lineno, and containing object exist on the same line. Since paths tend to be long, i find this line is always wrapping and breaking up the block structure of a printed exception message.

Traceback (most recent call last):
File C:\users\user\documents\python\lib\sound\effects\e cho.py, line 1423,in distribute_weights_evenly

By shorting paths (ONLY THOSE PATHS THAT LIVE IN A REGISTERED LIBRARY FOLDER), we can maintain printed exception message structure. I would go furtherand suggest moving the line number and containing object to their own lines.

Traceback (most recent call last):
File: "...\lib\sound\effects\echo.py"
Line: 1423
In: <function> "display_echo_waveform"
Trace:
...
 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      01-16-2013
On Thu, Jan 17, 2013 at 4:32 AM, Rick Johnson
<(E-Mail Removed)> wrote:
> On 1-16-2013 8:45 AM Steven D'Aprano wrote:
>> What personal library folder?

>
> The single MONOLITHIC folder you SHOULD be using to contain all your personal modules and scripts! But of course you are not doing this, only professionals are consistent.


On the contrary; it's easy to be consistent in clinical conditions,
but the Real World is very messy. Just a few reasons for scripts to
move around a bit:

* A few of the files need to be auto-updated by some remote system, so
they're stored in a directory owned by some other user to isolate
rsync

* Some files come from a package that's managed by an external
facility (eg apt-get), so there's no point moving them

* Part of the code gets extracted or decrypted on-the-fly from some
other source, so they're in /tmp

* The most important scripts are in a source-control managed tree

You can't rely on a single directory ("folder") containing all the
non-system code. If Python were to absolutely *demand* that, then I
suppose you could set up a bunch of symlinks (as long as you're on
Linux - on Windows, you MIGHT be able to do that), but it wouldn't
gain you anything.

>> 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 why the HELL would you place scripts on the desktop? So you can easily double click and run them? *giggles* Steven, have you heard of the new invention called a symbolic link?


Back in the early 1990s, on our OS/2 boxes, I got into the rather
useful habit of creating a file called 1. If I want an extension on
that, I can call it "1.cmd" for a REXX command, or whatever. If I need
two, "2.cmd" comes next. Saves you the trouble of coming up with a
name that fits your "standard library", and it keeps showing the thing
to you, demanding attention, and asking either to be renamed to
something permanent or finished with and deleted. Not all files are
for long-term use.

Mind you, some temporary names end up surviving. I still have a file
called 1 that stores snippets and cool quotes from the MUDs I play,
and when I made them web-accessible, I kept the name -
http://rosuav.com/1/ - after all, nothing is so permanent as a
temporary name. But I digress.

> So you understood my statement, however, you felt the need to correct me because i say "toe-mate-toe" and you say "toe-maught-toe"? interesting.


This is an argument I've had many times at work. Incorrect use of
language SHOULD be corrected, even when it's unambiguous; otherwise,
language becomes useless. If your and Steven's disagreement were
ignored, then sooner or later an ambiguous situation will arise, and
you'll understand different things from the same words. That's
dangerous. (And by the way, feel free to point out my own
spelling/grammar errors. I'm sure I've made some; one of the
fundamental rules of the universe is that it's impossible to nitpick
someone else's use of English without making your own mistakes.)

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

>
> Another new invention you may not know of are "command line switches"


Errors are notoriously hard to replicate. That's why production code
has logfiles. There's only one state that matters, and that's the
state the system was in when the one-off error occurred. The
programmer gets called in, he pulls up the log, he finds a traceback,
and gets to work. If that traceback is clear, readable, and carries
all the information he needs, it's a ten-minute job; if it's
abbreviated and he has to search the whole filesystem to find the
files, it's a huge and onerous task. (The middle ground, that he can
inspect some environment variable or whatever, isn't too much work,
but it's still unnecessary; the traceback could just contain it
directly.)

> Now /imaging/ all that, let's inspect these paths:


(Imagining, but I digress.)

> These two are invalid because you can only repair one problem at a time. And if you don't know the username of the person who's problem you are repairing, then you are not fit to repair the problem are you? Next!


Since when do usernames relate to people? And since when do you know
whose problem you're repairing? Going back to my scenario examples
above, the username might actually relate to the rsync source, or it
might be a descriptive-only name - for instance, I have a user
"content" on one of our servers, and whenever the web site's content
gets updated, it's rsync'd up to that user. So most of the files are
in /home/content/.../.../... rather than anything relating to a human.

>> E:\Temp\sound\effects\reverb.py

>
> Python source files should NEVER be under a temp directory, you can safely ignore this one.


Well, see above. Perfectly plausible justification for executing code from /tmp.

>> C:\Documents\python\sound\effects\reverb.py
>> F:\Development\python\lib\music\sound\effects\reve rb.py
>> G:\app-dev\sound\effects\reverb.py

>
> If these last three files really exist, and are /actually/ Python scripts, i would suggest charging extra so you could have time to teach this "dev" how to intelligently store files using structure and consistency.


And how to totally trash his system by not being allowed to have
multiple versions of things. And forbid him to use virtualenv, too.
Come to think of it, we should all use the Macbook Wheel file system
model - never mind about paths, just press both sides of the wheel and
get an alphabetized list of all files on your disk.

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


Additionally: When heaps of text is scrolling past you, it's very easy
to eyeball it for differences. When most or all of your paths start
with the same string, the eye will happily skip over it and find
what's important.

> Actually that is wrong. Because remember, the path, lineno, and containing object exist on the same line. Since paths tend to be long, i find this line is always wrapping and breaking up the block structure of a printed exception message.


A fair point. There are a few solutions to this; one is to abolish the
80-character width limit. When you're working in a log file (rather
than directly on a console) this is easy, and you can just scroll
horizontally. Another is...

> Traceback (most recent call last):
> File C:\users\user\documents\python\lib\sound\effects\e cho.py, line 1423, in distribute_weights_evenly
>
> By shorting paths (ONLY THOSE PATHS THAT LIVE IN A REGISTERED LIBRARY FOLDER), we can maintain printed exception message structure.


.... by shortening (please keep the 'en', this is an international
forum and we need to declare the language correctly - that way, you
can talk about 'shortdeing' German paths) the paths themselves. This
sounds like a job for a simple filter though, not for a language
feature.

> I would go further and suggest moving the line number and containing object to their own lines.
>
> Traceback (most recent call last):
> File: "...\lib\sound\effects\echo.py"
> Line: 1423
> In: <function> "display_echo_waveform"


I disagree. It's much more useful to have the file name and line, at
least, together; but what might be useful would be to go for a more
compact notation:
C:\users\user\documents\python\lib\sound\effects\e cho.py:1423:
display_echo_waveform
Trace....

This is a standard that many tools emit/recognize, and it's more
compact than showing "File" and "Line" in words. That might squidge
your traceback under the eighty-character limit. But whatever is done,
it's much easier to keep the file and line together; tools can more
easily work with it that way and smoothly take you to the appropriate
line in your editor, or whatever. Move the function name off, if you
need to, or just let it wrap. (That's why I put it at the end.)

ChrisA
 
Reply With Quote
 
 
 
 
alex23
Guest
Posts: n/a
 
      01-17-2013
On Jan 17, 3:32*am, Rick Johnson <(E-Mail Removed)> wrote:
> On 1-16-2013 8:45 AM Steven D'Aprano wrote:
>
> > What personal library folder?

>
> The single MONOLITHIC folder you SHOULD be using to contain all your
> personal modules and scripts! But of course you are not doing this,
> only professionals are consistent.


And here you reveal you have no idea whatsoever of what "professional"
programmers do.

In my workplace, we are each working on multiple projects
simultaneously, which will often require different versions of the
same libraries. How do I shove 2 versions of the same Python library
into this monolithic folder?

Since you're so fond of absolute declarations that will benefit the
Python community, here's on for you:

I've seen many times people responding to Rick as if he held
legitimate opinions and I believe I should define the situations in
which you should and shouldn't listen to him. Is he talking about
Tkinter? If not, he's talking garbage. If so, *and* he's including
code examples, then assess what he's saying carefully and just ignore
any pointless rhetoric.

He has NO suggestions that would improve Python as a whole because
he's coming from a place of theoretical-point-scoring over *pragmatic
and tested change*. If he was so keen on these suggestions of his,
there are a myriad of ways in which he could contribute back -
patches, pypi libraries, code samples - rather than rant and rant and
*rant* without producing anything. No one is going to redefine the
entire language of computer science on the say so of one annoying
idiot.

 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      01-17-2013
On 1/16/2013 11:43 AM, Rick Johnson wrote:
> 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?


I missed in your original post that you only want one consistent
personal library path abbreviated, leaving everything else alone. So the
above is not applicable. And a custom excepthook very easy.

How should the traceback mechanism will know what that path is?

To answer the objection about having to search the whole disk when on a
'foreign' machine, the top line of the traceback could be

Traceback: ... = C:/users/me/pystuff

>> 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 view so you can see the lineno in question (typical
> IDE stuff)...


I never noticed that. Thanks for the exchange of information.

--
Terry Jan Reedy

 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      01-19-2013
On Wednesday, January 16, 2013 6:51:31 PM UTC-6, Terry Reedy wrote:
> I missed in your original post that you only want one consistent
> personal library path abbreviated, leaving everything else alone. So the
> above is not applicable. And a custom excepthook very easy.
>
> How should the traceback mechanism -will- know what that path is?


Well, the jury is still deliberating on the specifics, however, as for myself, i would sway more to the /explicit/ side.

A few possibilities include:

* A configuration file. Python already checks the current
directory for ".pth" files, which it then reads and adds
the contained paths to sys.path -- most folks stopped
typing commands OVER and OVER on the commandline many
years ago. But to each his own.

* A runtime command or keyword placed in a script (YUCK!)

* A commandline switch (only good for members of the
python historical society.)
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      01-19-2013
On Wednesday, January 16, 2013 6:51:31 PM UTC-6, Terry Reedy wrote:
> I missed in your original post that you only want one consistent
> personal library path abbreviated, leaving everything else alone. So the
> above is not applicable. And a custom excepthook very easy.
>
> How should the traceback mechanism -will- know what that path is?


Well, the jury is still deliberating on the specifics, however, as for myself, i would sway more to the /explicit/ side.

A few possibilities include:

* A configuration file. Python already checks the current
directory for ".pth" files, which it then reads and adds
the contained paths to sys.path -- most folks stopped
typing commands OVER and OVER on the commandline many
years ago. But to each his own.

* A runtime command or keyword placed in a script (YUCK!)

* A commandline switch (only good for members of the
python historical society.)
 
Reply With Quote
 
Ramchandra Apte
Guest
Posts: n/a
 
      01-20-2013
On Wednesday, 16 January 2013 15:23:55 UTC+5:30, Terry Reedy wrote:
> 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


Right-click the file in the traceback and there is an "Go to file/line" option.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      01-20-2013
On Sat, 19 Jan 2013 19:15:55 -0800, Ramchandra Apte wrote:

[snip dozens of irrelevant quoted lines]
> Right-click the file in the traceback and there is an "Go to file/line"
> option.



Please trim your replies so that the reader doesn't have to scroll
through page after page of irrelevant text they've already read.

Thank you.


--
Steven
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      01-20-2013
On 1/20/2013 1:08 AM, Steven D'Aprano wrote:
> On Sat, 19 Jan 2013 19:15:55 -0800, Ramchandra Apte wrote:
>
> [snip dozens of irrelevant quoted lines]
>> Right-click the file in the traceback and there is an "Go to file/line"
>> option.

>
>
> Please trim your replies so that the reader doesn't have to scroll
> through page after page of irrelevant text they've already read.
>
> Thank you.


Quite aside from the fact that there already was a quick reply telling
me the same thing. A properly threaded reader would have placed it just
below my post.

--
Terry Jan Reedy

 
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