Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Chris Angelico]

On Fri, Jul 17, 2015 at 12:32 AM, Antoon Pardon
<antoon.pardon at 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.pardon at 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