On 07/16/2015 12:43 AM, Gregory Ewing wrote: > Antoon Pardon wrote: >> But it doesn't need to be all or nothing. How about the following >> possibility. >> When the runtime detects a serie of tail calls, it will keep the bottom three >> and the top three backtrace records of the serie. > Whatever value you choose for N, keeping only the > first/last N traceback frames will lead to someone > tearing their hair out.
I would say, that someone should get over himself. Traceback are not the only or even the most useful tool for debugging code. The current stack trace doesn't even contain the value's of the variables on the stack. So in case of Terry Reedy's example that stack trace would IMO have been next to useless. > I recently had an experience with some Java code > running in an environment which believed that nobody > would want to see more than about 30 traceback levels, > and chopped the rest off. Of course, the information > I desperately wanted was buried deeper than that... So? My experience is, that if you need to dig that deep in a stack trace, to find the information you need, you get it easier and faster by turning debug level logging on and going through the logs. YMMV. I also have to wonder, In my suggestion you would only start to loose traceback records after six consecutive tail calls. That IMO strongly suggest a loop. Most people suggest such a loop should be written iteratively. So my example would allow to keep 6 trace back records through such a loop while the iterative version would only keep one trace back record. But no one seems to be tearing their hair out for not having trace back records of the previous run through a loop. Yet you protest when trace back records disappear when such a loop is written recursively. > So, -1 on any arbitrarily chosen traceback cutoff. Noted. It just doesn't carry much weight with me. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
