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 benjamin.peterson, lukasz.langa, martin.panter, ncoghlan, ned.deily, steven.daprano, tds333, vstinner
Date 2016-09-13.04:32:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1473741163.921792.723886129.3ADB18B4@webmail.messagingengine.com>
In-reply-to <1473701699.17.0.669608607205.issue28092@psf.upfronthosting.co.za>
Content
On Mon, Sep 12, 2016, at 10:34, Łukasz Langa wrote:
> 
> Łukasz Langa added the comment:
> 
> Benjamin, what's the rationale behind switching those to inline
> functions? Does it improve runtime performance or build speed? If not, I
> don't understand why the additional complexity.

Macros for the stub case of dtrace are "fine" because they're so simple.
I mainly converted them to see if it would cause problems (e.g., this
bug report) before seeking further expansion.

Many of CPython's uglier macros could be replaced by inline funtions.
Inline functions provide the same performance benefit of macros while
improving type safety, debugability, and avoiding notorious macro quirks
like double evaluation.
History
Date User Action Args
2016-09-13 04:32:47benjamin.petersonsetrecipients: + benjamin.peterson, ncoghlan, tds333, vstinner, ned.deily, steven.daprano, lukasz.langa, martin.panter
2016-09-13 04:32:47benjamin.petersonlinkissue28092 messages
2016-09-13 04:32:46benjamin.petersoncreate