I expect no significant performance difference or a very low overhead for macros and functions using PyType_HasFeature().

PyType_HasFeature() is used by the following code in header files:

• PyVectorcall_Function()
• PyType_IS_GC()
• PyType_FastSubclass()

PyType_FastSubclass() is used by many PyXXX_Check() macros:

• PyLong_Check()
• PyBytes_Check(), PyUnicode_Check()
• PyTuple_Check(op), PyList_Check()
• PyDict_Check()
• PyExceptionClass_Check(), PyExceptionInstance_Check()

@serhiy-storchaka @methane: Do you expect such change to have an impact on performance? What do you think of the change?

Some PyType_HasFeature(cls, Py_TPFLAGS_HAVE_VERSION_TAG) are in Object/typeobject.c.
They are performance critical.
Can we have private inline function?

Can we have private inline function?

Yes, that's possible but I would prefer to add new functions to the internal C API for that. For example, add a fast _PyLong_Check() function.

In the past, I tried to reuse the same name for two implementation of the same function: one "slow" using a function call, one "fast" using a macro or static inline function.

I'm thinking at PyThreadState_GET(). The internal C API uses:

/* Redefine PyThreadState_GET() as an alias to _PyThreadState_GET() */
#undef PyThreadState_GET
#define PyThreadState_GET() _PyThreadState_GET()

The problem is that depending if the internal C API is included or not, you may get the slow or the fast function.

I changed my approach: use a different name for the fast function. _PyThreadState_GET() is guaranteed to be fast, but it's only provided by the internal C API. In short, using it ensures that you get the fast implementation, but also that the internal C API is included.

@methane: I added fast inlined version _PyType_HasFeature() and _PyType_IS_GC() for object.c and typeobject.c.