gh-133079: Remove Py_C_RECURSION_LIMIT & PyThreadState.c_recursion_remaining (GH-133080)

Both were added in 3.13, are undocumented, and don't make sense in 3.14 due to
changes in the stack overflow detection machinery (gh-112282).

PEP 387 exception for skipping a deprecation period: https://github.com/python/steering-council/issues/288
This commit is contained in:
Petr Viktorin 2025-04-29 12:56:20 +02:00 committed by GitHub
parent 208d06fd51
commit 0c26dbd16e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
5 changed files with 12 additions and 6 deletions

View file

@ -73,7 +73,8 @@ It will be more complex in the JIT.
Another important piece of VM state is the **thread state**, held in `tstate`.
The current frame pointer, `frame`, is always equal to `tstate->current_frame`.
The thread state also holds the exception state (`tstate->exc_info`) and the recursion counters (`tstate->c_recursion_remaining` and `tstate->py_recursion_remaining`).
The thread state also holds the exception state (`tstate->exc_info`) and
recursion tracking data (`tstate->py_recursion_remaining`, `tstate->c_stack*`).
The thread state is also used to access the **interpreter state** (`tstate->interp`), which is important since the "eval breaker" flags are stored there (`tstate->interp->ceval.eval_breaker`, an "atomic" variable), as well as the "PEP 523 function" (`tstate->interp->eval_frame`).
The interpreter state also holds the optimizer state (`optimizer` and some counters).