Daniel Diniz <[EMAIL PROTECTED]> added the comment: Antoine,
Thanks for your analysis. I still believe this is a regression for the case described, but take my opinion with a grain of salt :) >> looking at the code for _Py_CheckRecursiveCall(), I don't think it >> is a bug but a feature. It does seem to be working as designed, if that is a desirable behavior then this issue should be closed. > This is actually what happens in your example: when the normal > recursion limit is hit and a RuntimeError is raised, you > immediately catch the exception and run into a second infinite > loop while the normal recursion check is temporarily disabled: > the N+50 check then does its job. Except that it wasn't an infinite loop in 2.5 and isn't in trunk: it terminates on overflower's except. That's why I think this is a regression. Besides being different behavior, it seems weird to bail out on a recursion issue instead of dealing with it. Your showcase is a better way of getting an infinite loop in trunk than the one I mentioned, but AFAIK we are more comfortable with infinite loops than with fatal errors. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3555> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
