GH-91079: Rename C_RECURSION_LIMIT to Py_C_RECURSION_LIMIT

[vstinner]

Symbols of the C API should be prefixed by "Py_" to avoid conflict with existing names in 3rd party C extensions on #include <Python.h>.

• Issue: Implement stack overflow protection for supported platforms #91079

[vstinner]

@iritkatriel: Are you ok with this rename?

[vstinner]

cc @markshannon

[iritkatriel]

Do users define this?

[vstinner]

I don't know if it's relevant to support that. It's supposed to be a constant built into Python, no?

[vstinner]

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

[vstinner]

vstinner removed the needs backport to 3.12

It's too late to backport to Python 3.12.

[vstinner]

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 :-)

[vstinner]

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).