homepage

On the other hand, Antoine is correct in that we _could_ use the existing infrastructure and count PyIter_Next() as a recursion in the same way as entering the ceval loop is a recursion. Extra checking in there would hardly slow down the execution much. (but it would have to do its job only when invoking a "c" implemented iternext routine...)
I tried to come up with other ways that we could create deeply nested C function calls...
Here's one:
...
 a = (a, a)
 b = (b, b)
a < b
This however gets caught by this code:
 if (Py_EnterRecursiveCall(" in comparison"))
 return NULL;
 res = do_richcompare(v, w, op);
 Py_LeaveRecursiveCall();
So obviously someone thought this could be an issue.
However:
...
 a = {1: a}
repr(a)
will generate the same crash. (tuple repr and list repr have guards, dict repr not)
So, there are various ways to get c recursion to overflow the C stack. Some of them have been patched throughout the years, others not.
We could try to identify all the different ways. We could for example add guards in PyObject_Repr() rather than individual types. But I'm sure we will leave holes in place like the OP discovered with deeply nested iterators.