Ensure that every function pointer in every PyTypeObject is set to a non-NULL default, to spare the cost of checking for NULL with every use. As a basic example, consider PyNumber_Negative:

PyObject *
PyNumber_Negative(PyObject *o)
{
    PyNumberMethods *m;

    if (o == NULL) {
        return null_error();
    }

    m = o->ob_type->tp_as_number;
    if (m && m->nb_negative)
        return (*m->nb_negative)(o);

    return type_error("bad operand type for unary -: '%.200s'", o);
}

If "tp_as_number" and "nb_negative" were always guaranteed non-NULL, then the function could omit the second if statement, and invoke the function pointer directly. To maintain the existing behavior, the default nb_negative function would be set to the following:

PyObject* nb_negative_default(PyObject *o) {
    return type_error("bad operand type for unary -: '%.200s'", o);
}

This removes two NULL-checks from the PyNumber_Negative. Many other operators and builtins would be able to benefit in the same way.

I believe it would also make sense to inline the 'as' structures (tp_as_async, tp_as_number, tp_as_sequence, tp_as_mapping, and tp_as_buffer), instead of having them be pointers. This would save one pointer dereference with each use. But this would have API compatibility consequences, so for this change it is off the table.

1. This will increase the size of type object. Most types are not numbers, not collections and don't support the buffer protocol, thus save memory for tp_as_number, tp_as_sequence, tp_as_mapping and tp_as_buffer. This also can increase the time of type creation.

2. This will make harder testing that the particular protocol is supported (e.g. see PyIndex_Check or PyObject_CheckBuffer). And this will break any third-party code that does this directly, without using C API.

3. Calling function instead of executing inlined code after checking can increase stack consumption and slow down execution (see the usage of tp_descr_get).

serhiy.storchaka:

1) Where tp_as_number would normally be NULL, instead it would point to a fixed PyNumberMethods structure containing the default functions. This would make the memory increase negligible, as all non-number types would use the same structure.

2) If this is behavior we want to formally support, then we should provide macros for it. (all they must do is compare against the default pointer value, rather than NULL). Are there particular extension(s) you suspect may be doing this?

3) This has to be handled on a case-by-case basis. I would not remove inlined optimizations. If there are some fields that truly benefit from remaining NULL, those can be left alone. I would like to focus on the functions for which the common case (in code without type errors) is to make the indirect call.

For all the reasons Serhiy mentioned, I recommend rejecting this request.  This was an intentional and long-standing design decision. A substantial part of the Python ecosystem depends on it.