Possibly Pythonic Tail Call Optimization (TCO/TRE)
ethan at stoneleaf.us
Thu Jul 16 19:04:26 CEST 2015
On 07/16/2015 09:43 AM, Chris Angelico wrote:
> 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.
If we had a general mechanism then we would also need to have a setting somewhere so we could adjust which frames to keep when debugging.
I must say I don't see much value in a stack trace that says a called b called c called a called b called c called a called ... -- particularly when the line quoted has only the variable names, not
their values, so you can't see what's changing.
Of this whole thread, though, I like the 'recurse' keyword proposal best -- I have no issues with the programmer specifying when to ditch the stack frame, but maybe that's my assembly roots showing. ;)
More information about the Python-list