gh-145497: Compute static builtin type count at compile time via X-macro#151004
gh-145497: Compute static builtin type count at compile time via X-macro#151004corona10 wants to merge 1 commit into
Conversation
| // All other static types (unless initialized elsewhere) | ||
| for (size_t i=0; i < Py_ARRAY_LENGTH(static_types); i++) { | ||
| PyTypeObject *type = static_types[i]; | ||
| if (type == NULL) { |
| // their base classes. | ||
| for (Py_ssize_t i=Py_ARRAY_LENGTH(static_types)-1; i>=0; i--) { | ||
| PyTypeObject *type = static_types[i]; | ||
| if (type == NULL) { |
|
cc @ZeroIntensity Do you have interested in this change? |
|
🤖 New build scheduled with the buildbot fleet by @corona10 for commit 21952b5 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F151004%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
ZeroIntensity
left a comment
There was a problem hiding this comment.
Thanks for the ping. What's the net benefit here? #149139 added a test that prevents us from breaking _Py_MAX_MANAGED_STATIC_BUILTIN_TYPES in the future. I'm a little concerned that we're making things worse by adding macro gymnastics.
I think a simpler approach would be to continue using multiple static-type arrays, but export their lengths as static variables and compute _Py_MAX_MANAGED_STATIC_TYPES as the sum of their lengths. Then, we just create static_types in _PyTypes_InitTypes instead of doing it statically.
There was a problem hiding this comment.
I'm not a huge fan of moving all static types to their own header file. I think it makes it harder to track down where static types are being defined, because it separates the code from the definition.
Uh oh!
There was an error while loading. Please reload this page.