Adding type flags & struct members

Hello,
Here’s a part of C API that some of you might have opinions on.

My PEP 697 proposes adding a new type flag. And I’m considering adding yet another ht_* member to all heap type objects (for better debugging/less undefined behavior in API, and possible speedups). I’ve done these additions before, but I feel that I don’t know enough about these shared resources.

The 32-bit space for type flags is slowly running out, as a few are added each release. Does anyone have a plan for when it runs out? (Switch to long long? Move private flags elsewhere?)

The size of type objects affects everyone, but there’s few of them so it seems new members aren’t too big a deal. Is that right?

What kind of questions should I ask myself when adding these? Do we have some unwritten process? (Or maybe written – I couldn’t find one.) Who’d like to get pinged on things like this?

2 Likes

Maybe we should reserve a bit now to indicate “has extended flags” so that we can use it later on to indicate that another field should be looked at? Or to restructure the flags into packed enums (e.g. the 8 _SUBCLASS flags could be reduced to a 3 bit int).

There’s no need to actually change anything yet, just to make sure that we have a bit set aside to use for this when we need it (and before we inadvertently fill up the 32-bits without thinking about this).

1 Like

We don’t need an extra bit in each type. In the Python version that introduces the new field, all types will have it.
But a new place to look in will not work with all the API that uses intPyTypeObject.tp_flags, PyTypeSpec.flags, PyType_HasFeature(), etc. These wi’ll work for existing flags, but “extended” ones will need new alternatives.
It would be best if the new alternatives work with the old flags, but that might be tricky.

We can not change existing flags, they’re part of the public API (and stable ABI).