[issue1553375] Add traceback.print_full_exception()

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1553375] Add traceback.print_full_exception()

Change by Piotr Dobrogost : -- nosy: +piotr.dobrogost ___ Python tracker ___

[issue1553375] Add traceback.print_full_exception()

Robert Collins added the comment: That should be straightforward - its just sequence suffix/prefix overlap detection, and FrameSummary (unlike frames) can be compared with ==. So yes, I think it makes it easier. It's not on my immediate itch-scratching though, but if someone were to poke at

[issue1553375] Add traceback.print_full_exception()

Nick Coghlan added the comment: Adding Robert Collins to the nosy list to see if the recent traceback changes make it easier to implement this one correctly. Robert, for context, the general idea here is to be able to stitch the traceback for a caught exception together with the stack trace

[issue1553375] Add traceback.print_full_exception()

Mark Lawrence added the comment: The functionality described here certainly seems wanted and there's been some other work on the traceback module recently so could we get this into 3.5? -- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.4 ___

[issue1553375] Add traceback.print_full_exception()

Antoine Pitrou added the comment: I recently re-wrote something like this, so I think this is useful. I wonder if it wouldn't be nice to add a caret or some similar marker indicating the frame where the exception was caught, e.g.: Traceback (most recent call last, catch point highlighted):

[issue1553375] Add traceback.print_full_exception()

Changes by Andrew Svetlov andrew.svet...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___

[issue1553375] Add traceback.print_full_exception()

Florent Xicluna added the comment: Changeset ba014543ed2c (3.2a4) references this issue. -- nosy: +flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___

[issue1553375] Add traceback.print_full_exception()

Changes by Éric Araujo mer...@netwok.org: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing

[issue1553375] Add traceback.print_full_exception()

Changes by Daniel Stutzbach stutzb...@google.com: -- nosy: +stutzbach versions: +Python 3.3 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___

[issue1553375] Add traceback.print_full_exception()

Nick Coghlan ncogh...@gmail.com added the comment: Note that my suggestion was to move the if statement out of the loop as-is: you would still be pulling the traceback to display from the caught exception rather than displaying the stack from the current point of execution. If you want the

[issue1553375] Add traceback.print_full_exception()

Pascal Chambon chambon.pas...@gmail.com added the comment: I dont understand, if we use traceback.print_stack(), it's the stack at the exception handling point which will be displayed. In my view, the interesting think was not the stack trace at the point where the exception is being handled,

[issue1553375] Add traceback.print_full_exception()

R. David Murray rdmur...@bitdance.com added the comment: I agree with you, Pascal, but I think Nick is saying that that information is not actually available. I don't fully understand why, but he knows vastly more about Python internals than I do so I'll take his word for it. It might be

[issue1553375] Add traceback.print_full_exception()

Nick Coghlan ncogh...@gmail.com added the comment: As per my response to RDM on python-dev, I think the patch is misguided as it currently stands. The traceback on an exception is built up as the stack unwinds. The stack above the frame containing the exception handler obviously hasn't been

[issue1553375] Add traceback.print_full_exception()

Nick Coghlan ncogh...@gmail.com added the comment: If the allframes flag is pursued further, then the stack trace should be added (with an appropriate header clause) after the entire exception chain has been printed (including the exception currently being handled). --

[issue1553375] Add traceback.print_full_exception()

Nick Coghlan ncogh...@gmail.com added the comment: Note that after the loop over the values is complete, the final value of tb should correctly refer to the traceback for the exception currently being handled regardless of whether or not any chaining is involved. So moving the stack printing

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: I've implemented an optional keyword argument stack_info (defaulting to False) for all logging calls. If specified as True, a line Stack (most recent call last): is printed, followed by the output of traceback.print_stack(). This is

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Re. the change in r86467, you can test using this simple script: http://pastebin.com/ZXs3sXDW -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375

[issue1553375] Add traceback.print_full_exception()

R. David Murray rdmur...@bitdance.com added the comment: Vinay, your example with communicate only works because you removed the [:-1]. If you run your version against a debug build, the tests will fail. I'm updating the patch with a version that works with both a non-debug and a debug

[issue1553375] Add traceback.print_full_exception()

Pascal Chambon chambon.pas...@gmail.com added the comment: Indeed I don't understand the following part : +Traceback (most recent call last): + File testmod.py, line 16, in module +{exception_action} + File testmod.py, line

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: The regression tests are failing for me, see http://gist.github.com/618117 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Also, fullstack remains in one place in the docs. Should now say allframes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375

[issue1553375] Add traceback.print_full_exception()

R. David Murray rdmur...@bitdance.com added the comment: Pascal: my question exactly. The question is whether the code is accurately reflecting the state of the python stack at exception time (which it seems like it ought to), in which case I don't understand how Python handles the chained

[issue1553375] Add traceback.print_full_exception()

R. David Murray rdmur...@bitdance.com added the comment: After giving this some thought, I'm sure that the observed results are not what we want, so I've changed the test to be the result that we want. I haven't been able to figure out what is causing it, and am starting to wonder if it

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: It's still failing - the existing gist has been updated with the output from the new run: http://gist.github.com/618117 -- ___ Python tracker rep...@bugs.python.org

[issue1553375] Add traceback.print_full_exception()

R. David Murray rdmur...@bitdance.com added the comment: vinay: duh. I'm using a debug build and my test is slicing off the refount line. I think there's a helping in test.support for that... -- ___ Python tracker rep...@bugs.python.org

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: David, I don't think it's that - I think it's the subprocess comms. This works: def _do_test(self, program, exc_text): with open(self.testfn, 'w') as testmod: testmod.writelines(program.format(

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Also, the use of literal 'testmod.py' in _do_test should probably be replaced by self.testfn. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: On reflection, perhaps we should use sys.stdin.encoding to decode the value received from the subprocess. What do you think? -- ___ Python tracker rep...@bugs.python.org

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Attached a patch which works on my machine. -- Added file: http://bugs.python.org/file19180/full_traceback5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375

[issue1553375] Add traceback.print_full_exception()

Pascal Chambon chambon.pas...@gmail.com added the comment: Is that normal to have two methods test_full_traceback_is_full at the same place, in full_traceback.patch / r.david.murray / 2010-08-04 02:32 ? format_exception should have the same semantic as print_exception indeed. --

[issue1553375] Add traceback.print_full_exception()

R. David Murray rdmur...@bitdance.com added the comment: No, that would be a bug, thanks. Also thanks for reminding me about this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375

[issue1553375] Add traceback.print_full_exception()

R. David Murray rdmur...@bitdance.com added the comment: I like 'allframes', so I changed to that. The updated patch also adds the allframes parameter to format_exception. In going over the tests I realized that I'm not sure the output for the case of chain=True is correct. Opinions? If it

[issue1553375] Add traceback.print_full_exception()

Changes by Vinay Sajip vinay_sa...@yahoo.co.uk: -- nosy: +vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: This functionality would be useful in format_exception(), too, so it might be better to implement in format_exception_only(). This latter function formats the exception part of a traceback, so it makes sense to implement it here. I would

[issue1553375] Add traceback.print_full_exception()

Changes by Vinay Sajip vinay_sa...@yahoo.co.uk: -- Removed message: http://bugs.python.org/msg114972 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___

[issue1553375] Add traceback.print_full_exception()

Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: This functionality would be useful in format_exception(), too. I prefer fullstack to full as it's clearer what the 'full' pertains to. An alternative might be upperframes or allframes. -- ___

[issue1553375] Add traceback.print_full_exception()

R. David Murray rdmur...@bitdance.com added the comment: Updated patch with unit tests and docs. I realized that I'd forgotten to test chained exceptions. It looks like when the Interpreter prints a traceback all the exceptions in the chain are printed fully, which makes sense. Adopting

[issue1553375] Add traceback.print_full_exception()

Ray.Allen ysj@gmail.com added the comment: David Murray, where is the patch? -- nosy: +ysj.ray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___

[issue1553375] Add traceback.print_full_exception()

R. David Murray rdmur...@bitdance.com added the comment: Morning does make a difference. Revised patch that also works at the top level of a module. (Let's see if I can manage to actually attach it this time...) -- keywords: +patch Added file:

[issue1553375] Add traceback.print_full_exception()

R. David Murray rdmur...@bitdance.com added the comment: Here's a proof of concept patch that adds a 'fullstack' option to print_exception. The problem with this concept is what happens when you use it on an exception caught at the top level of a module. I'm not entirely clear on why

[issue1553375] Add traceback.print_full_exception()

Changes by Thomas Guettler guet...@thomas-guettler.de: -- nosy: +guettli ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___

[issue1553375] Add traceback.print_full_exception()

Thomas Guettler guet...@thomas-guettler.de added the comment: It would be very nice if logging.info('...', exc_info=True) shows the calling/upper frames, too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375

[issue1553375] Add traceback.print_full_exception()

Thomas Guettler guet...@thomas-guettler.de added the comment: Related #9427 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___

[issue1553375] Add traceback.print_full_exception()

Pascal Chambon chambon.pas...@gmail.com added the comment: What's the status of this (imo quite useful) new traceback function ? Shall I provide some help ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375

[issue1553375] Add traceback.print_full_exception()

Changes by Pascal Chambon chambon.pas...@gmail.com: -- nosy: +pakal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list

[issue1553375] Add traceback.print_full_exception()

Changes by Gabriel Genellina gagsl-...@yahoo.com.ar: -- nosy: +gagenellina ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___

[issue1553375] Add traceback.print_full_exception()

Changes by news1234 news1...@free.fr: -- nosy: +news1234 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list mailing

[issue1553375] Add traceback.print_full_exception()

Changes by Daniel Diniz aja...@gmail.com: -- keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375 ___ ___ Python-bugs-list

[issue1553375] Add traceback.print_full_exception()

Changes by Daniel Diniz aja...@gmail.com: -- priority: normal - low stage: - test needed versions: +Python 2.7, Python 3.1 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1553375