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>?
--
http://mail.python.org/mailman/listinfo/python-list
