Fibonacci series recursion error

[harrismh777]

Chris Angelico wrote:
> The recursion is in the last block. Note that it calls a function,
> then keeps going. It doesn't fork. There are two CALL_FUNCTION
> opcodes, called*sequentially*. In terms of the call stack, there is
> only ever one of those two calls active at any given time.

RuntimeError: maximum recursion depth exceeded in comparison
[36355 refs]

can any one help

[ @ Ian, Chris, Thomas ]

Thanks, guys, but I think y'all are still missing my point/question, as 
interesting as these discussions are... something is wrong (might be my 
understanding)...

... CPython must be making function calls by placing stack-frames on the 
call stack... which has a relatively small limit. Python does crappy 
tail optimization (one of the reasons to avoid recursion in Python) and 
yes, this is an infinite recursion... doh... but the main point for this 
part of the discussion is that the "maximum recursion depth exceeded in 
comparison" runtime error is posted because there are more stack-frames 
being posted to the call stack than there is call-stack to hold them! 
We might change this with sys.setrecursionlimit, but that's dangerous; 
but the bottom line is that in order for the recursion depth runtime 
error to be posted, somebody placed too many stack-frames on the call 
stack... in this case about 36,355 of them...   yes, the base-case is 
coded wrong and the process is infinite, the point is that tail 
processing doesn't even get to run... the silly thing pummels the call 
stack with stack-frames (obviously exceeding 20) and the runtime error 
is posted. If your point is that the infinite process is the problem, I 
agree. But my point is that the cpu crunch and the rate at which the 
call stack is filled has to do with the double call (which never finds 
tail processing).

What am I missing here>?