GeezerVison

See #22838 for example usage.

IMO that's a code style issue, and PEP7 has nothing against it. I'd rather keep it as is.
The declaration is already C99-style: it's not at the beginning of the function :)

Thanks!

And thanks for the other review – this PR includes the changes you pointed out :)

When a type has no subclass but a long MRO, _PyType_GetModuleByDef() has to iterate on the N parent classes before reaching the last one which will match. Would it be more efficient to iterator on the MRO in the reverse order?

It would make the function slower for subclasses, but faster for direct instance of the type.

Usually, when I read "get", I expect a O(1) operation. I'm fine if the first call fills a cache and is slower. But here, every call has a complexity of O(n) where n is the length of the MRO tuple. Would it make sense to rename the function to _PyType_FindModuleByDef() to announce that it can be slow?

Anyway, thanks for adding this function! It will unblock porting many extension modules to multi-phase init and heap types in https://bugs.python.org/issue1635741 !

About _PyType_FindModuleByDef() name, here is a more concrete example: the PR #23124 converts the array extension to multi-phase init. The current PR defines:

#define get_array_state_by_type(tp) \
    (get_array_state(_PyType_GetModuleByDef(tp, &arraymodule)))
#define get_array_state_by_class(cls) \
    (get_array_state(PyType_GetModule(cls)))

I would prefer to use "find" in the first macro, to better highlight that "get_array_state_by_type()" is a fast attribute access:

#define find_array_state_by_type(tp) \
    (get_array_state(_PyType_FindModuleByDef(tp, &arraymodule)))
#define get_array_state_by_type(cls) \
    (get_array_state(PyType_GetModule(cls)))

Usually, when I read "get", I expect a O(1) operation.

Hm, I don't expect that. "get" can mean many things :)

I'll keep it in mind for if/when it becomes public API. I don't think it's worth changing the name now, after all the discussion.