Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #36886 > unrolled thread

PyWart: Exception error paths far too verbose

Back to article view | Back to comp.lang.python

Contents

  PyWart: Exception error paths far too verbose Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-15 21:59 -0800
    PyWart: Exception error paths far too verbose donarb <donarb@nwlink.com> - 2013-01-16 00:31 -0800
      Re: PyWart: Exception error paths far too verbose Chris Angelico <rosuav@gmail.com> - 2013-01-16 19:39 +1100
    Re: PyWart: Exception error paths far too verbose Terry Reedy <tjreedy@udel.edu> - 2013-01-16 04:53 -0500
      Re: PyWart: Exception error paths far too verbose Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-16 08:43 -0800
        Re: PyWart: Exception error paths far too verbose Terry Reedy <tjreedy@udel.edu> - 2013-01-16 19:51 -0500
          Re: PyWart: Exception error paths far too verbose Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-18 16:34 -0800
          Re: PyWart: Exception error paths far too verbose Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-18 16:34 -0800
      Re: PyWart: Exception error paths far too verbose Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-16 08:43 -0800
      Re: PyWart: Exception error paths far too verbose Ramchandra Apte <maniandram01@gmail.com> - 2013-01-19 19:15 -0800
        Re: PyWart: Exception error paths far too verbose Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-20 06:08 +0000
          Re: PyWart: Exception error paths far too verbose Terry Reedy <tjreedy@udel.edu> - 2013-01-20 11:08 -0500
    Re: PyWart: Exception error paths far too verbose Michael Torrie <torriem@gmail.com> - 2013-01-16 07:20 -0700
      Re: PyWart: Exception error paths far too verbose Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-16 08:31 -0800
      Re: PyWart: Exception error paths far too verbose Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-16 08:31 -0800
    Re: PyWart: Exception error paths far too verbose Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-16 14:45 +0000
      Re: PyWart: Exception error paths far too verbose Rick Johnson <rantingrickjohnson@gmail.com> - 2013-01-16 09:32 -0800
        Re: PyWart: Exception error paths far too verbose Chris Angelico <rosuav@gmail.com> - 2013-01-17 08:21 +1100
        Re: PyWart: Exception error paths far too verbose alex23 <wuwei23@gmail.com> - 2013-01-16 16:33 -0800

#36886 — PyWart: Exception error paths far too verbose

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

[toc] | [next] | [standalone]

#36887

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.

[toc] | [prev] | [next] | [standalone]

#36888

On Wed, Jan 16, 2013 at 7:31 PM, donarb <donarb@nwlink.com> 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

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#36906

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 needs me 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 view so you can see the lineno in question (typical IDE stuff)... but most devs prefer to use IDEs with less bugs asinine interfaces :-)

[toc] | [prev] | [next] | [standalone]

#36924

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

[toc] | [prev] | [next] | [standalone]

#37037

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

[toc] | [prev] | [next] | [standalone]

#37038

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

[toc] | [prev] | [next] | [standalone]

#36907

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 needs me 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 view so you can see the lineno in question (typical IDE stuff)... but most devs prefer to use IDEs with less bugs asinine interfaces :-)

[toc] | [prev] | [next] | [standalone]

#37105

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

Right-click the file in the traceback and there is an "Go to file/line" option.

[toc] | [prev] | [next] | [standalone]

#37106

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

[toc] | [prev] | [next] | [standalone]

#37113

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

[toc] | [prev] | [next] | [standalone]

#36894

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.

[toc] | [prev] | [next] | [standalone]

#36904

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.

[toc] | [prev] | [next] | [standalone]

#36905

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.

[toc] | [prev] | [next] | [standalone]

#36899

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


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

[toc] | [prev] | [next] | [standalone]

#36908

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

[toc] | [prev] | [next] | [standalone]

#36917

On Thu, Jan 17, 2013 at 4:32 AM, Rick Johnson
<rantingrickjohnson@gmail.com> 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\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.

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

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

[toc] | [prev] | [next] | [standalone]

#36921

On Jan 17, 3:32 am, Rick Johnson <rantingrickjohn...@gmail.com> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web