On Fri, Apr 22, 2016 at 12:30 AM, Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: > On 21 April 2016 at 15:12, Chris Angelico <ros...@gmail.com> wrote: >> On Fri, Apr 22, 2016 at 12:01 AM, Oscar Benjamin >> <oscar.j.benja...@gmail.com> wrote: >>> In the recursive stack overflow case what you'll usually have is >>> >>> 1) A few frames leading up to the start of recursion >>> 2) A long repetitive sequence of frames >>> 3) A few frames at the end showing how the exception was ultimately >>> triggered. >>> >>> You just need to find the cycle that makes that big long sequence. >> >> If the stack got overflowed, there won't usually be a part 3, as part >> 2 is the bit that hits sys.recursionlimit (unless increasing the >> recursion limit by a finite number would solve the problem). For other >> exceptions, yes, this is what you'd see. > > If you have: > > def f(x): > return g(x+1) > > def g(x): > x = h(x) # <-- stack can overflow inside here > return f(x+1) > > # etc. > > So you have a long sequence that goes f, g, f, g but at the end the > stack can overflow while (not recursively) calling h leaving a small > non-cyclic part at the end.
Right, good point. Forgot about that. So this situation can be triggered by anywhere up to <cycle length> lines up. Not as helpful an optimization now. Oh well. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
