Benjamin:
> Why do we need this Py_STATIC_INLINE macro? If you want to have one for enabling always inline, that's fine with me, since it's compiler-specific.

For about the name, there is already Py_LOCAL_INLINE which also uses "static inline", but has a very different usage: "Py_LOCAL can be used instead of static to get the fastest possible calling convention for functions that are local to a given module." So I chise "Py_STATIC_INLINE" name, it describes the basic implementation ("static inline TYPE").

Py_STATIC_INLINE() is designed to replace a preprocessor macro with a function, when you care that the code is "always inlined". (Maybe the name is not perfect ;-))

Honestly, I'm not sure that it really matters that the function is "always" inlined. The main issue is that "static" requires to duplicate the function in each file which uses the macro, when the function cannot/is not inlined.


Previously, you asked me:

> Does this slow down debug builds at all? It probably will not end will if Py_INCREF is ever not inlined.

That's why I wrote Py_STATIC_INLINE() to "force" inlining and PR 10094 to enable inlining for Debug build on MSVC.


> But the current Py_STATIC_INLINE macro seems to conflate linkage with always-inline behavior.

I'm not sure that I get it. Do you talk about "static" inside the macro? bpo-33407 modifies Py_DEPRECATED() to support Visual Stuido, but it requires to modify how the macro is used: it now must be used at the start, rather than at the end:
https://github.com/python/cpython/pull/8980/files

I chose to put "static" and "inline" in the same macro. We already have many other similar macros like PyAPI_FUNC(TYPE) and Py_LOCAL(TYPE). I would like to have a common way to "declare a function behaving as a macro".


Please see also the discussion on the PR itself, Neil discuss what's the best way to declare an inline function:
https://github.com/python/cpython/pull/10079#issuecomment-433230587

By the way, was it you who required "static inline" support in PEP 7? :-)