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?
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).
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
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).