Make traceback messages aware of line continuation
Consider the following: assert \ 1 == 0, \ "error" It will produce: Traceback (most recent call last): File "foo.py", line 3, in <module> "error" AssertionError: error The information about the statement which produced the exception is lost. Instead I would expect: Traceback (most recent call last): File "foo.py", line 1, in <module> assert \ 1 == 0, \ "error" AssertionError: error Not sure how easy this is to implement but I think it would be a good enhancement. Thoughts? --- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/
2013/4/29 Giampaolo Rodola' <g.rodola@gmail.com>:
Consider the following:
assert \ 1 == 0, \ "error"
It will produce:
Traceback (most recent call last): File "foo.py", line 3, in <module> "error" AssertionError: error
The information about the statement which produced the exception is lost. Instead I would expect:
Traceback (most recent call last): File "foo.py", line 1, in <module> assert \ 1 == 0, \ "error" AssertionError: error
Not sure how easy this is to implement but I think it would be a good enhancement. Thoughts?
--- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/
Shame on me. It seems this is already tracked in http://bugs.python.org/issue12458 Let's say this is a revamping attempt then. =) --- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/
On 4/29/2013 1:42 PM, Giampaolo Rodola' wrote:
2013/4/29 Giampaolo Rodola' <g.rodola@gmail.com>:
Consider the following:
assert \ 1 == 0, \ "error"
It will produce:
Traceback (most recent call last): File "foo.py", line 3, in <module> "error" AssertionError: error
The information about the statement which produced the exception is lost. Instead I would expect:
Traceback (most recent call last): File "foo.py", line 1, in <module> assert \ 1 == 0, \ "error" AssertionError: error
Not sure how easy this is to implement but I think it would be a good enhancement. Thoughts?
Very dubious idea, for multiple reasons given on the issue.
It seems this is already tracked in http://bugs.python.org/issue12458
For your example, the OP of that issue would replace the line '"error"' with 'assert', which would not be helpful at all. If your statement was assert some_fairly_long_expression_with_calls ==\ something_else, "error" then is would not be clear that backing up would be helpful. Terry
On Mon, 29 Apr 2013 20:40:37 -0400 Terry Jan Reedy <tjreedy@udel.edu> wrote:
The information about the statement which produced the exception is lost. Instead I would expect:
Traceback (most recent call last): File "foo.py", line 1, in <module> assert \ 1 == 0, \ "error" AssertionError: error
Not sure how easy this is to implement but I think it would be a good enhancement. Thoughts?
Very dubious idea, for multiple reasons given on the issue.
It seems this is already tracked in http://bugs.python.org/issue12458
For your example, the OP of that issue would replace the line '"error"' with 'assert', which would not be helpful at all. If your statement was
assert some_fairly_long_expression_with_calls ==\ something_else, "error"
then is would not be clear that backing up would be helpful.
Perhaps you've missed that Giampaolo's suggestion was to print the *entire* statement, not just one line chosen at random? There's one thing this proposal would make more difficult, which is machine-processing of tracebacks. Otherwise it does look better to me. Regards Antoine.
Would it also understand line continuations using parentheses ( the more common style)? On Tuesday, April 30, 2013, Antoine Pitrou wrote:
On Mon, 29 Apr 2013 20:40:37 -0400 Terry Jan Reedy <tjreedy@udel.edu <javascript:;>> wrote:
The information about the statement which produced the exception is
lost.
Instead I would expect:
Traceback (most recent call last): File "foo.py", line 1, in <module> assert \ 1 == 0, \ "error" AssertionError: error
Not sure how easy this is to implement but I think it would be a good enhancement. Thoughts?
Very dubious idea, for multiple reasons given on the issue.
It seems this is already tracked in http://bugs.python.org/issue12458
For your example, the OP of that issue would replace the line '"error"' with 'assert', which would not be helpful at all. If your statement was
assert some_fairly_long_expression_with_calls ==\ something_else, "error"
then is would not be clear that backing up would be helpful.
Perhaps you've missed that Giampaolo's suggestion was to print the *entire* statement, not just one line chosen at random?
There's one thing this proposal would make more difficult, which is machine-processing of tracebacks. Otherwise it does look better to me.
Regards
Antoine.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org <javascript:;> http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
2013/4/30 Antoine Pitrou <solipsis@pitrou.net>:
On Mon, 29 Apr 2013 20:40:37 -0400 Terry Jan Reedy <tjreedy@udel.edu> wrote:
The information about the statement which produced the exception is lost. Instead I would expect:
Traceback (most recent call last): File "foo.py", line 1, in <module> assert \ 1 == 0, \ "error" AssertionError: error
Not sure how easy this is to implement but I think it would be a good enhancement. Thoughts?
Very dubious idea, for multiple reasons given on the issue.
It seems this is already tracked in http://bugs.python.org/issue12458
For your example, the OP of that issue would replace the line '"error"' with 'assert', which would not be helpful at all. If your statement was
assert some_fairly_long_expression_with_calls ==\ something_else, "error"
then is would not be clear that backing up would be helpful.
Perhaps you've missed that Giampaolo's suggestion was to print the *entire* statement, not just one line chosen at random?
Exactly. 2013/4/30 Guido van Rossum <guido@python.org>:
Would it also understand line continuations using parentheses ( the more common style)?
Yes, definitively (see http://bugs.python.org/msg188159). I came up with this idea because this is especially annoying during tests, where it's not rare to have long self.assert* statements split over multiple lines. Every time you get a failure you'll likely have to open the test file with an editor and go to line N in order to figure out what the entire assert statement looked like. --- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/
+1 It would be great to have this feature. 2013/4/30 Giampaolo Rodola' <g.rodola@gmail.com>
2013/4/30 Antoine Pitrou <solipsis@pitrou.net>:
On Mon, 29 Apr 2013 20:40:37 -0400 Terry Jan Reedy <tjreedy@udel.edu> wrote:
The information about the statement which produced the exception is
lost.
Instead I would expect:
Traceback (most recent call last): File "foo.py", line 1, in <module> assert \ 1 == 0, \ "error" AssertionError: error
Not sure how easy this is to implement but I think it would be a good enhancement. Thoughts?
Very dubious idea, for multiple reasons given on the issue.
It seems this is already tracked in http://bugs.python.org/issue12458
For your example, the OP of that issue would replace the line '"error"' with 'assert', which would not be helpful at all. If your statement was
assert some_fairly_long_expression_with_calls ==\ something_else, "error"
then is would not be clear that backing up would be helpful.
Perhaps you've missed that Giampaolo's suggestion was to print the *entire* statement, not just one line chosen at random?
Exactly.
2013/4/30 Guido van Rossum <guido@python.org>:
Would it also understand line continuations using parentheses ( the more common style)?
Yes, definitively (see http://bugs.python.org/msg188159). I came up with this idea because this is especially annoying during tests, where it's not rare to have long self.assert* statements split over multiple lines. Every time you get a failure you'll likely have to open the test file with an editor and go to line N in order to figure out what the entire assert statement looked like.
--- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Felipe Cruz http://about.me/felipecruz
On Wed, May 1, 2013 at 12:41 AM, Felipe Cruz <felipecruz@loogica.net> wrote:
+1
It would be great to have this feature.
As Terry explained on the tracker issue, printing the entire expression is hugely problematic, as it means that long definition displays (e.g. for dictionaries or lists) will show a huge amount of noise, rather than the subexpression that actually triggered the exception. It is far better to break up the code to avoid long lines in the first place, even if that involves creating "redundant" assignment statements for subexpressions. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (6)
-
Antoine Pitrou -
Felipe Cruz -
Giampaolo Rodola' -
Guido van Rossum -
Nick Coghlan -
Terry Jan Reedy