PyWart: Exception error paths far too verbose

Discussion in 'Python' started by Rick Johnson, Jan 16, 2013.

  1. Rick Johnson

    Rick Johnson Guest

    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
    Rick Johnson, Jan 16, 2013
    #1
    1. Advertising

  2. Rick Johnson

    donarb Guest

    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.
    donarb, Jan 16, 2013
    #2
    1. Advertising

  3. On Wed, Jan 16, 2013 at 7:31 PM, donarb <> 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
    Chris Angelico, Jan 16, 2013
    #3
  4. Rick Johnson

    Terry Reedy Guest

    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
    Terry Reedy, Jan 16, 2013
    #4
  5. 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.
    Michael Torrie, Jan 16, 2013
    #5
  6. 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
    Steven D'Aprano, Jan 16, 2013
    #6
  7. Rick Johnson

    Rick Johnson Guest

    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.
    Rick Johnson, Jan 16, 2013
    #7
  8. Rick Johnson

    Rick Johnson Guest

    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.
    Rick Johnson, Jan 16, 2013
    #8
  9. Rick Johnson

    Rick Johnson Guest

    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 :)
    Rick Johnson, Jan 16, 2013
    #9
  10. Rick Johnson

    Rick Johnson Guest

    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 :)
    Rick Johnson, Jan 16, 2013
    #10
  11. Rick Johnson

    Rick Johnson Guest

    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 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\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 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:
    ...
    Rick Johnson, Jan 16, 2013
    #11
  12. On Thu, Jan 17, 2013 at 4:32 AM, Rick Johnson
    <> 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
    Chris Angelico, Jan 16, 2013
    #12
  13. Rick Johnson

    alex23 Guest

    On Jan 17, 3:32 am, Rick Johnson <> 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.
    alex23, Jan 17, 2013
    #13
  14. Rick Johnson

    Terry Reedy Guest

    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
    Terry Reedy, Jan 17, 2013
    #14
  15. Rick Johnson

    Rick Johnson Guest

    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.)
    Rick Johnson, Jan 19, 2013
    #15
  16. Rick Johnson

    Rick Johnson Guest

    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.)
    Rick Johnson, Jan 19, 2013
    #16
  17. 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.
    Ramchandra Apte, Jan 20, 2013
    #17
  18. 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
    Steven D'Aprano, Jan 20, 2013
    #18
  19. Rick Johnson

    Terry Reedy Guest

    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
    Terry Reedy, Jan 20, 2013
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dan Simper
    Replies:
    5
    Views:
    2,794
    Andrea Desole
    Jan 19, 2005
  2. Al Jones

    Is this too far off topic??

    Al Jones, Jan 13, 2005, in forum: HTML
    Replies:
    8
    Views:
    460
    Richard Cornford
    Jan 15, 2005
  3. Andy Dingley
    Replies:
    45
    Views:
    1,625
    Andy Mabbett
    Jun 11, 2006
  4. Jake Emerson
    Replies:
    3
    Views:
    334
    Jake Emerson
    Jun 27, 2006
  5. RC
    Replies:
    2
    Views:
    427
    Chase Preuninger
    Jan 8, 2008
Loading...

Share This Page