This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author benjamin.peterson
Recipients Aaron Hall, benjamin.peterson, mark.dickinson, miss-islington, serhiy.storchaka, thatiparthy, vstinner
Date 2018-10-28.20:45:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On Fri, Oct 26, 2018, at 03:18, STINNER Victor wrote:
> STINNER Victor <> added the comment:
> 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").

I would like to see Py_LOCAL_INLINE removed, too, fwiw.

> 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 ;-))

"always inline" is different from "static inline". So, it's not appropriate to make a macro named the latter that has the former former.

> 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:
> 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".

We don't want functions that behave like macros... otherwise, we would be writing macros. If we want a function to always be inlined, we should explicitly request that from the compiler.

> Please see also the discussion on the PR itself, Neil discuss what's the 
> best way to declare an inline function:
> By the way, was it you who required "static inline" support in PEP 7? :-)

Yes, which is why we shouldn't need a macro to write it.
Date User Action Args
2018-10-28 20:45:53benjamin.petersonsetrecipients: + benjamin.peterson, mark.dickinson, vstinner, serhiy.storchaka, thatiparthy, Aaron Hall, miss-islington
2018-10-28 20:45:53benjamin.petersonlinkissue35059 messages
2018-10-28 20:45:53benjamin.petersoncreate