This was also going to go out after i posted the display/displaytb patch. But anyway, let's see what you all think. I propose the following stylistic changes to traceback printing: 1. If there is no function name for a given level in the traceback, just omit the ", in ?" at the end of the line. 2. If a given level of the traceback is in a method, instead of just printing the method name, print the class and the method name. 3. Instead of beginning each line with: File "foo.py", line 5 print the line first and drop the quotes: Line 5 of foo.py In the common interactive case that the file is a typed-in string, the current printout is File "<stdin>", line 1 and the following is easier to read in my opinion: Line 1 of <stdin> Here is an example: >>> class Spam: ... def eggs(self): ... return self.ham ... >>> s = Spam() >>> s.eggs() Traceback (innermost last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in eggs AttributeError: ham With the suggested changes, this would print as Traceback (innermost last): Line 1 of <stdin> Line 3 of <stdin>, in Spam.eggs AttributeError: ham -- ?!ng "In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand." -- Gerald Holton
Ka-Ping Yee <ping@lfw.org>:
I propose the following stylistic changes to traceback printing:
1. If there is no function name for a given level in the traceback, just omit the ", in ?" at the end of the line.
2. If a given level of the traceback is in a method, instead of just printing the method name, print the class and the method name.
3. Instead of beginning each line with:
File "foo.py", line 5
print the line first and drop the quotes:
Line 5 of foo.py
In the common interactive case that the file is a typed-in string, the current printout is
File "<stdin>", line 1
and the following is easier to read in my opinion:
Line 1 of <stdin>
Here is an example:
>>> class Spam: ... def eggs(self): ... return self.ham ... >>> s = Spam() >>> s.eggs() Traceback (innermost last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in eggs AttributeError: ham
With the suggested changes, this would print as
Traceback (innermost last): Line 1 of <stdin> Line 3 of <stdin>, in Spam.eggs AttributeError: ham
IMHO, this is not a good idea. Emacs users like me want traceback labels to be *more* like C compiler error messages, not less. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> The United States is in no way founded upon the Christian religion -- George Washington & John Adams, in a diplomatic message to Malta.
On Tue, 2 May 2000, Eric S. Raymond wrote:
Ka-Ping Yee <ping@lfw.org>:
With the suggested changes, this would print as
Traceback (innermost last): Line 1 of <stdin> Line 3 of <stdin>, in Spam.eggs AttributeError: ham
IMHO, this is not a good idea. Emacs users like me want traceback labels to be *more* like C compiler error messages, not less.
I suppose Python could go all the way and say things like Traceback (innermost last): <stdin>:3 foo.py:25: in Spam.eggs AttributeError: ham but that might be more intimidating for a beginner. Besides, you Emacs guys have plenty of programmability anyway :) You would have to do a little parsing to get the file name and line number from the current format; it's no more work to get it from the suggested format. (What i would really like, by the way, is to see the values of the function arguments on the stack -- but that's a lot of work to do in C, so implementing this with the help of repr.repr will probably be the first thing i do with sys.displaytb.) -- ?!ng
Ka-Ping Yee <ping@lfw.org>:
With the suggested changes, this would print as
Traceback (innermost last): Line 1 of <stdin> Line 3 of <stdin>, in Spam.eggs AttributeError: ham
On Tue, 2 May 2000, Eric S. Raymond wrote:
IMHO, this is not a good idea. Emacs users like me want traceback labels to be *more* like C compiler error messages, not less.
Ka-Ping Yee : [...]
Besides, you Emacs guys have plenty of programmability anyway :) You would have to do a little parsing to get the file name and line number from the current format; it's no more work to get it from the suggested format.
I like pings proposed traceback output. But beside existing Elisp code there might be other software relying on a particular format. As a long time vim user I have absolutely no idea about other IDEs. So before changing the default format this should be carefully checked.
(What i would really like, by the way, is to see the values of the function arguments on the stack -- but that's a lot of work to do in C, so implementing this with the help of repr.repr will probably be the first thing i do with sys.displaytb.)
I'm eagerly waiting to see this. ;-) Regards, Peter
Ka-Ping Yee <ping@lfw.org>:
With the suggested changes, this would print as
Traceback (innermost last): Line 1 of <stdin> Line 3 of <stdin>, in Spam.eggs AttributeError: ham
ESR:
IMHO, this is not a good idea. Emacs users like me want traceback labels to be *more* like C compiler error messages, not less.
Ping:
I suppose Python could go all the way and say things like
Traceback (innermost last): <stdin>:3 foo.py:25: in Spam.eggs AttributeError: ham
but that might be more intimidating for a beginner.
Besides, you Emacs guys have plenty of programmability anyway :) You would have to do a little parsing to get the file name and line number from the current format; it's no more work to get it from the suggested format.
Not sure -- I think I carefully designed the old format to be one of the formats that Emacs parses *by default*: File "...", line ... Your change breaks this.
(What i would really like, by the way, is to see the values of the function arguments on the stack -- but that's a lot of work to do in C, so implementing this with the help of repr.repr will probably be the first thing i do with sys.displaytb.)
Yes, this is much easier in Python. Watch out for values that are uncomfortably big or recursive or that cause additional exceptions on displaying. --Guido van Rossum (home page: http://www.python.org/~guido/)
On 02 May 2000, Ka-Ping Yee said:
I propose the following stylistic changes to traceback printing:
1. If there is no function name for a given level in the traceback, just omit the ", in ?" at the end of the line.
+0 on this: it doesn't really add anything, but it does neaten things up.
2. If a given level of the traceback is in a method, instead of just printing the method name, print the class and the method name.
+1 here too: this definitely adds utility.
3. Instead of beginning each line with:
File "foo.py", line 5
print the line first and drop the quotes:
Line 5 of foo.py
-0: adds nothing, cleans nothing up, and just generally breaks things for no good reason.
In the common interactive case that the file is a typed-in string, the current printout is
File "<stdin>", line 1
and the following is easier to read in my opinion:
Line 1 of <stdin>
OK, that's a good reason. Maybe you could special-case the "<stdin>" case? How about <stdin>, line 1 ? Greg
On Tue, 2 May 2000, Greg Ward wrote:
In the common interactive case that the file is a typed-in string, the current printout is
File "<stdin>", line 1
and the following is easier to read in my opinion:
Line 1 of <stdin>
OK, that's a good reason. Maybe you could special-case the "<stdin>" case?
...and "<string>", and "<console>", and perhaps others... ? File "<string>", line 3 just looks downright clumsy the first time you see it. (Well, it still looks kinda clumsy to me or i wouldn't be proposing the change.) Can someone verify the already-parseable-by-Emacs claim, and describe how you get Emacs to do something useful with bits of traceback? (Alas, i'm not an Emacs user, so understanding just how the current format is useful would help.) -- ?!ng
On 02 May 2000, Ka-Ping Yee said:
I propose the following stylistic changes to traceback printing:
1. If there is no function name for a given level in the traceback, just omit the ", in ?" at the end of the line.
Greg Ward expresses my sentiments:
+0 on this: it doesn't really add anything, but it does neaten things up.
2. If a given level of the traceback is in a method, instead of just printing the method name, print the class and the method name.
+1 here too: this definitely adds utility.
3. Instead of beginning each line with:
File "foo.py", line 5
print the line first and drop the quotes:
Line 5 of foo.py
-0: adds nothing, cleans nothing up, and just generally breaks things for no good reason.
In the common interactive case that the file is a typed-in string, the current printout is
File "<stdin>", line 1
and the following is easier to read in my opinion:
Line 1 of <stdin>
OK, that's a good reason. Maybe you could special-case the "<stdin>" case? How about
<stdin>, line 1
?
I'd special-case any filename that starts with < and ends with > -- those are all made-up names like <string> or <stdin>. You can display them however you like, perhaps In "<string>", line 3 For regular files I'd leave the formatting alone -- there are tools out there that parse these. (E.g. Emacs' Python mode jumps to the line with the error if you run a file and it begets an exception.) --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> For regular files I'd leave the formatting alone -- there are GvR> tools out there that parse these. (E.g. Emacs' Python mode GvR> jumps to the line with the error if you run a file and it GvR> begets an exception.) py-traceback-line-re is what matches those lines. It's current definition is (defconst py-traceback-line-re "[ \t]+File \"\\([^\"]+\\)\", line \\([0-9]+\\)" "Regular expression that describes tracebacks.") There are probably also gud.el (and maybe compile.el) regexps that need to be changed too. I'd rather see something that outputs the same regardless of whether it's a real file, or something "fake". Something like Line 1 of <stdin> Line 12 of foo.py should be fine. I'm not crazy about something like File "foo.py", line 12 In <stdin>, line 1 -Barry
[... completely eliding Ping's note and stealing his subject ...] On a not-quite unrelated tack, I wonder if traceback printing can be enhanced in the case where Python code calls a function or method written in C (possibly calling multiple C functions), which in turn calls a Python function that raises an exception. Currently, the Python functions on either side of the C functions are printed, but no hint of the C function's existence is displayed. Any way to get some indication there's another function in the middle? Thanks, -- Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ "We have become ... the stewards of life's continuity on earth. We did not ask for this role... We may not be suited to it, but here we are." - Stephen Jay Gould
[Skip]
On a not-quite unrelated tack, I wonder if traceback printing can be enhanced in the case where Python code calls a function or method written in C (possibly calling multiple C functions), which in turn calls a Python function that raises an exception. Currently, the Python functions on either side of the C functions are printed, but no hint of the C function's existence is displayed. Any way to get some indication there's another function in the middle?
In some cases, that's a good thing -- in others, it's not. There should probably be an API that a C function can call to add an entry onto the stack. It's not going to be a trivial fix though -- you'd have to manufacture a frame object. I can see two options: you can do this "on the way out" when you catch an exception, or you can do this "on the way in" when you are called. The latter would require you to explicitly get rid of the frame too -- probably both on normal returns and on exception returns. That seems hairier than only having to make a call on exception returns; but it means that the C function is invisible to the Python debugger unless it fails. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (7)
-
bwarsaw＠python.org -
Eric S. Raymond -
Greg Ward -
Guido van Rossum -
Ka-Ping Yee -
pf＠artcom-gmbh.de -
Skip Montanaro