You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since 3.12, sys.setrecursionlimit does not control the recursion limit of the C stack (it's hardcoded in Py_C_RECURSION_LIMIT, due to #91079), while the 3.13 docs say
Set the maximum depth of the Python interpreter stack to limit.
This limit prevents infinite recursion from causing an overflow of the C stack and crashing Python.
The fallout can be seen in #112215 (basically, any code that uses lru_cache in combination with sys.setrecursionlimit is potentially, or actually, broken in 3.12, while still working in 3.11) or in #107263 (which was papered over with an increase of Py_C_RECURSION_LIMIT, not really fixed).
This is an obvious change of behaviour, as code working in 3.11 can easily be broken in 3.12, as found in #112215
$ python3.11 <fib.py
139423224561697880139724382870407283950070256587697307264108962948325571622863290691557658876222521294125
$ python3.12 <fib.py
Traceback (most recent call last):
File "<stdin>", line 15, in <module>
File "<stdin>", line 13, in fib
File "<stdin>", line 13, in fib
File "<stdin>", line 13, in fib
[Previous line repeated 496 more times]
RecursionError: maximum recursion depth exceeded
Such changes should carry a warning in the documentation.
Potentially, any recursive Python code combining C recursion (in a module, e.g. lru_cache, via @lru_cache decorator) with increased (beyond the hardcoded Py_C_RECURSION_LIMIT) sys.setrecursionlimit is bound to be broken in 3.12.
I believe the whole hardcoding of Py_C_RECURSION_LIMIT has to be fixed (perhaps with a separate API provided to change it), as it's a regression and an incompatible change of code behaviour, but meanwhile the docs have to reflect the reality.
The text was updated successfully, but these errors were encountered:
In particular, we are unable to move from python 3.11 to anything higher, since we can no longer pickle.dump our objects, even if sys.setrecursionlimit is called beforehand for example.
Since 3.12,
sys.setrecursionlimit
does not control the recursion limit of the C stack (it's hardcoded inPy_C_RECURSION_LIMIT
, due to #91079), while the 3.13 docs sayThe fallout can be seen in #112215 (basically, any code that uses
lru_cache
in combination withsys.setrecursionlimit
is potentially, or actually, broken in 3.12, while still working in 3.11) or in #107263 (which was papered over with an increase ofPy_C_RECURSION_LIMIT
, not really fixed).This is an obvious change of behaviour, as code working in 3.11 can easily be broken in 3.12, as found in #112215
Such changes should carry a warning in the documentation.
Potentially, any recursive Python code combining C recursion (in a module, e.g.
lru_cache
, via@lru_cache
decorator) with increased (beyond the hardcodedPy_C_RECURSION_LIMIT
)sys.setrecursionlimit
is bound to be broken in 3.12.I believe the whole hardcoding of
Py_C_RECURSION_LIMIT
has to be fixed (perhaps with a separate API provided to change it), as it's a regression and an incompatible change of code behaviour, but meanwhile the docs have to reflect the reality.The text was updated successfully, but these errors were encountered: