On Fri, Jul 17, 2015 at 12:32 AM, Antoon Pardon <antoon.par...@rece.vub.ac.be> wrote: > On 07/16/2015 04:00 PM, Chris Angelico wrote: >> On Thu, Jul 16, 2015 at 11:56 PM, Antoon Pardon >> <antoon.par...@rece.vub.ac.be> wrote: >>> Fine, I should have been more clear. >>> >>> The stack trace as it is generally produced on stderr after an uncought >>> exception, doesn't contain the values of the variables on the stack. >> Sure. So you catch it at top level and grab whatever info you need. In >> some frameworks, this is already done for you - an uncaught exception >> from application code drops you into a debugger that lets you explore >> and even execute code at any level in the stack. > > What is unclear about "as it is generally produced on stderr"? That you > can do a whole lot of stuff, doesn't mean that this whole lot of stuff is > part of what generally happens. When people on this list ask a person > to include the stacktrace with the description of the problem, they > don't mean something that includes the values of the variables.
True. That said, though, it's not a justification for dropping stack frames; even in the form that's printed to stderr, there is immense value in them. It may be possible to explicitly drop frames that a programmer believes won't be useful, but a general and automated dropping of tail-call information will do more harm than good. The fact that some frameworks can show _even more_ helpful information out of a traceback only makes this stronger. ChrisA -- https://mail.python.org/mailman/listinfo/python-list