Logged In: YES 
user_id=31435

OK, Python's recursion check does trigger if "del c" is 
included at the end of the __del__ method.  However, as-is, 
the destruction of c is a side effect of __del__'s frame 
getting decref'ed, and the latter happens at the end of 
PyEval_EvalCodeEx().  eval_frame() is long gone by then, 
and tstate->recursion_depth is checked in the latter.

To be clear, there is a deep chain of Python frames, but 
they're all in the process of being destructed, and tstate-
>recursion_depth has already been decremented (it's just 3 
at the time this blew up on my Windows box):  eval_frame() 
is not on the C stack (except for a few times at the base 
of the C stack).

So, in this sense, it's a failure of the recursion-depth 
hacks to model the true depth of the C stack.  Note there 
are actually 10 levels of C stack for each Python level 
here:  PyEval_EvalCodeEx decrefs the frame, which invokes 
_Py_Dealloc, then to frame_dealloc, which decrefs c and 
triggers _Py_Dealloc -> instance_dealloc, which finds a 
__del__ method and so does PyEval_CallObjectWithKeywords -> 
PyObject_Call -> instancemethod_call -> PyObject_Call -> 
function_call -> PyEval_EvalCodeEx, and we start all over 
again.

No bright ideas here, so unassigned again.