@iritkatriel: Are you ok with this rename?

cc @markshannon

@iritkatriel: I removed #ifndef Py_C_RECURSION_LIMIT. Would you mind to review again the PR?

vstinner removed the needs backport to 3.12

It's too late to backport to Python 3.12.

I don't think that it makes sense to override the Py_C_RECURSION_LIMIT constant. Python does hardcode this constant in its code. For example, init_threadstate() sets tstate->c_recursion_remaining = Py_C_RECURSION_LIMIT;.

Building Python with a different Py_C_RECURSION_LIMIT value sounds like a borderline usecase. If someone cares about fine tuning Py_C_RECURSION_LIMIT, I would suggest adding a ./configure option. Currently, building Python with a different C_RECURSION_LIMIT value leads to inconsistencies for C extensions built with the default Py_C_RECURSION_LIMIT value (1500).

Including <Python.h> and overriding Py_C_RECURSION_LIMIT sounds like a bad idea: Python will anyway uses its hardcoded constants (ex: in init_threadstate()), changing the constant doesn't change Python behavior. It only leads to inconsistency.

In short, IMO it's a good thing to remove #ifndef C_RECURSION_LIMIT :-)

Since Py_C_RECURSION_LIMIT value is different on WASI, I modified test.pythoninfo to log the value, to ease debugging test failures related to recursion. Recently, I added sys.getrecursionlimit to test.pythoninfo when I fixed test_tomllib recursion error (commit 8ff1142).