PyWart: Exception error paths far too verbose

[Rick Johnson]

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\effects\reverb.py
> E:\Temp\sound\effects\reverb.py
> F:\Development\python\lib\music\sound\effects\reverb.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 would be 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\effects\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\reverb.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\echo.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 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"
  Trace:
     ...