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 rhettinger
Recipients corona10, erlendaasland, pablogsal, rhettinger, vstinner
Date 2021-03-16.23:34:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1615937665.09.0.513838632185.issue43502@roundup.psfhosted.org>
In-reply-to
Content
Be careful about performance.  We know for sure that macros will inline.  In contrast, inline functions might or might not inline (there are rules for when it can be done).  When applied across source files, inlining often only occurs with an LTO build — any other build can't inline across object files.  Historically, we've never had to depend on LTO, so that would be a regression for some users.  We've already have a performance bug that needed to be reverted because of too aggressive conversion of macros to inline functions.  

A problem with these blanket PRs is that they second guess the original developer who may have made a conscious and informed decision to use a macro.  If you really think that developer was wrong, they should be included in the conversation and given the chance to opt in or out.  Otherwise, we're mechanically undoing previous intelligent efforts.

Ideally, there needs to be a more nuanced view than "macros are bad, inline functions are good".
History
Date User Action Args
2021-03-16 23:34:25rhettingersetrecipients: + rhettinger, vstinner, corona10, pablogsal, erlendaasland
2021-03-16 23:34:25rhettingersetmessageid: <1615937665.09.0.513838632185.issue43502@roundup.psfhosted.org>
2021-03-16 23:34:24rhettingerlinkissue43502 messages
2021-03-16 23:34:24rhettingercreate