Some explanation of what this code does would be useful.
If you don't like the warning - figure it out! :)

Why do you think that it's dead? The function is being called, after all...

@filmor it might be doing something that is no longer needed and is essentially no-op

I guess 'dead' might not be the best term here, but from the looks of the code I can't determine its intent.

I'll give it a try understanding it, but this warning is currently extremely verbose for something that is at least not really a problem :)

@filmor see you after returning from the rabbit hole! 😂 (P.S. I never tried this particular one yet)

Wow, this one tracks through until the initial commit, 15 years ago :) @brianlloyd, you don't happen to know what exactly you were trying to achieve here? :)

This code is required for things like PyNumber_Check to work, see e.g. https://github.com/python/cpython/blob/31ff96712e8f89ac1056c2da880b44650002219f/Objects/abstract.c#L830-L837

I don't think it is necessarily required, since our types are structured exactly like PyHeapTypeObject, but this can be revisited if we ever restructure our generated types to be created completely using Python's methods instead of this hackery. It's definitely valid to do this explicit initialisation here.

It seems wrong to have it present for types that do not implement numbers protocol.

From the code you linked it looks like our types would pass PyNumber_Check. - no it does not, as nb_index, nb_float or nb_int are not set in this function.

Also, what is the relationship between sq_length and tp_as_sequence and why does one get set to another? And the same for the other two fields...

sq_length etc. are the first fields of the respective abstract types. If your type /could/ implement one of them, they have to be set. And our types (being modelled in memory after heap types) always have the respective sections, so it's correct to set them. The checks pass as soon as one of the slots is filled.