[Python-Dev] Start writing inlines rather than macros?

[Stephen J. Turnbull]

Skip Montanaro writes:
 > On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
 > > Well, if we must maintain macros, let's maintain them everywhere and
 > > avoid the burden of two different implementations for the same thing.
 > 
 > Would it be possible to generate the macro versions from the
 > inline/static versions where necessary, as some sort of pre-compile
 > step?

To do that in general is a hard problem, unless you're a C compiler
that already supports inlining.  I'm not sure how easy it would be to
define rules that support the inlines Python demands for performance,
and yet makes function to macro conversion easy.

I think it makes much more sense to look at rewriting the macros by
hand so that they emulate the necessary amount of function semantics
(eg, providing argument type-checking in debug builds, not mutating
arguments unless passed by reference, evaluating arguments exactly
once, etc).  XEmacs has a lot of these for precisely the reason this
thread started (plus the recognition at the time we started this
practice that a number of our platforms could not be trusted to inline
certain performance-critical routines).  They're spelled using the
same conventions as functions, so macros that don't obey those rules
stick out.

Then these function-like macros could be #ifdef'd with the inline
functions, with some (automated) comparison testing on appropriate
benchmarks by building with and without -dDONT_TRUST_INLINE.  And then
beta-testing by defaulting to #undef DONT_TRUST_INLINE.  Then wait for
cries of pain -- if none, remove the dead #ifdef branches in the last
beta or so.

Yes, this involves a certain amount of work, but I think it's bounded.
There should be no extra maintenance of the #ifdef'd parts compared to
the maintenance required to fix bugs resulting from change from macro
semantics to inline semantics anyway, unless changing the macros is
mistake-prone -- which will be recognized immediately.