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 kristjan.jonsson
Recipients Arfrever, benjamin.peterson, brett.cannon, georg.brandl, kristjan.jonsson, larry, loewis, pitrou, rhettinger, serhiy.storchaka, skrah, taleinat, vstinner
Date 2014-02-27.09:56:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1393494982.99.0.967313431565.issue20440@psf.upfronthosting.co.za>
In-reply-to
Content
Are you referring to the Py_LOCAL_INLINE macro?
I see that we have no Py_INLINE.  Py_LOCAL_INLINE includes the "static" qualifier, and in fact, if there is no "USE_INLINE" defined, then all that it does is to add "static".

Would having a "Py_INLINE(type)" macro, that is the same, but without the static (except when USE_INLINE is false) make a difference?  It would be a bit odd to have Py_LOCAL_INLINE() functions defined in the headers.

I'm not sure that there is any practical difference between "static inline" and "inline".  But there is a difference between "static" and "inline".

It would be great if we could start writing stuff like the Py_INCREF() and Py_DECREF() as functions rather than macros, but for this to happen we must be able to trust that they are really inlined.
History
Date User Action Args
2014-02-27 09:56:23kristjan.jonssonsetrecipients: + kristjan.jonsson, loewis, brett.cannon, georg.brandl, rhettinger, pitrou, vstinner, taleinat, larry, benjamin.peterson, Arfrever, skrah, serhiy.storchaka
2014-02-27 09:56:22kristjan.jonssonsetmessageid: <1393494982.99.0.967313431565.issue20440@psf.upfronthosting.co.za>
2014-02-27 09:56:22kristjan.jonssonlinkissue20440 messages
2014-02-27 09:56:22kristjan.jonssoncreate