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
{{ message }}
Repository navigation
Adjust _Py_MAX_MANAGED_STATIC_BUILTIN_TYPES value automatically #145497
When a new built-in type is introduced, _Py_MAX_MANAGED_STATIC_BUILTIN_TYPES needs to be updated accordingly.
(e.g., 3e2f5c1, #145496 (comment))
This is quite painful, and sometimes we even forget to adjust it. To prevent this kind of issue, we may need a way to update it automatically, or add a test that verifies it is set correctly.
How do you want to compute _Py_MAX_MANAGED_STATIC_BUILTIN_TYPES value?
The static_types array in Objects/object.c only has 118 entries (where _PyUOpExecutor_Type is only available if _Py_TIER2 macro is defined), whereas _Py_MAX_MANAGED_STATIC_BUILTIN_TYPES is equal to 201 (it should be 202, PR gh-145496 fix it). So I don't see the direct relationship between static_types and _Py_MAX_MANAGED_STATIC_BUILTIN_TYPES.
Another example of this causing issues: #149121. At the very least, it would be nice to have a test that verified the number, so we don't run into weird issues on the main branch when we forget to fix it.
So I don't see the direct relationship between static_types and _Py_MAX_MANAGED_STATIC_BUILTIN_TYPES.
Hm, what is _Py_MAX_MANAGED_STATIC_BUILTIN_TYPES if not the length of static_types? Where do the other ~80 entries come from?
On PR gh-161455, ERROR: test_pytype_ready_always_sets_tp_type (test.test_capi.test_misc.TestStaticTypes.test_pytype_ready_always_sets_tp_type) fails on iOS with RuntimeError: no more available basic static types. I suppose that it's related to this issue.
Activity
vstinner commentedon Mar 4, 2026
How do you want to compute
_Py_MAX_MANAGED_STATIC_BUILTIN_TYPESvalue?The
static_typesarray inObjects/object.conly has 118 entries (where_PyUOpExecutor_Typeis only available if_Py_TIER2macro is defined), whereas_Py_MAX_MANAGED_STATIC_BUILTIN_TYPESis equal to201(it should be202, PR gh-145496 fix it). So I don't see the direct relationship betweenstatic_typesand_Py_MAX_MANAGED_STATIC_BUILTIN_TYPES.corona10 commentedon Mar 4, 2026
I don't think about it concretely, but I believe that we need to find a better way.
ZeroIntensity commentedon Apr 29, 2026
Another example of this causing issues: #149121. At the very least, it would be nice to have a test that verified the number, so we don't run into weird issues on the main branch when we forget to fix it.
Hm, what is
_Py_MAX_MANAGED_STATIC_BUILTIN_TYPESif not the length ofstatic_types? Where do the other ~80 entries come from?JelleZijlstra commentedon Apr 29, 2026
Seems the rest are mostly exception classes and a few others that aren't in
static_typesitself.Here's a list from printing every type that gets added:
static.txt
encukou commentedon Apr 29, 2026
See also #149121.
gh-145497: Use same size of static_types array in all builds (GH-149139)
StanFromIreland commentedon May 2, 2026
Triage: with #149139 merged, can this be closed?
StanFromIreland commentedon May 2, 2026
Ooops wrong button.
corona10 commentedon May 2, 2026
Yes we can close! Thank you @encukou
encukou commentedon May 4, 2026
Sadly, that PR is just a workaround. It would still be nice to adjust this automatically.
pythongh-145497: Check _Py_NUM_MANAGED_STATIC_EXTRA_TYPES at runtime
pythongh-145497: Check _Py_NUM_MANAGED_STATIC_EXTRA_TYPES at runtime
vstinner commentedon Sep 15, 2026
Please see my new PR gh-157582 which actually counts static types at Python startup (in debug mode) to make sure that macros are still up to date.
vstinner commentedon Nov 15, 2026
On PR gh-161455,
ERROR: test_pytype_ready_always_sets_tp_type (test.test_capi.test_misc.TestStaticTypes.test_pytype_ready_always_sets_tp_type)fails on iOS withRuntimeError: no more available basic static types. I suppose that it's related to this issue.