Skip Montanaro writes: > On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou <solip...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
