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 vstinner
Recipients Aaron Hall, benjamin.peterson, mark.dickinson, miss-islington, serhiy.storchaka, thatiparthy, vstinner
Date 2018-10-28.21:42:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
>> 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.

Oh ok. So if we decide to keep it, it should be renamed to Py_STATIC_ALMOST_ALWAYS_INLINE() or something like that :-)

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

Oh. It seems like I misunderstood you.

I understood that you required to have zero impact on performance on debug build.

*I* want to use functions because it's the regular C language: regular scope rules, no preprocessor magic, the compiler detects errors if the function is misused, etc.

But I'm not sure about the drawbacks of converting a macro to a function. I don't want to be the only one responsible to regressions :-) If you support the change, we can drop "__attribute__((always_inline))" and use "regular" "static inline" functions :-)

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

Ok ok.

I updated my PR 10079 to simply use "static inline".
Date User Action Args
2018-10-28 21:42:41vstinnersetrecipients: + vstinner, mark.dickinson, benjamin.peterson, serhiy.storchaka, thatiparthy, Aaron Hall, miss-islington
2018-10-28 21:42:41vstinnersetmessageid: <>
2018-10-28 21:42:41vstinnerlinkissue35059 messages
2018-10-28 21:42:39vstinnercreate