Hi there.

The discussion on http://bugs.python.org/issue20440 started me thinking that much of this

bikeshedding could be avoided if we weren‘t constrained to writing macros for all of this stuff.

For example,  a

Py_INLINE(PyObject *) Py_Incref(PyObject *obj)
{

    Py_INCREF(obj);
    return obj;

}

could be used in a Py_Assign() function, if a new reference were wanted:

Py_INLINE(void) Py_Assign(PyObject ** target, PyObject *obj)
{

    PyObject *tmp = *target;

    *target = tmp;

    Py_DECREF(tmp);

}

So that you could then safely write code like

Py_Assign(&MyVar, Py_Incref(obj));

This would also allow you to stop writing various super macros to try to cater to all possible permutations.

Now, Larry Hastings pointed out that we support C89 which doesn’t support Inlines.  Rather than suggesting here that we update that compatibility requirement,

how about adding a Py_INLINE() macro.?  This would be like Py_LOCAL_INLINE() except that it would drop the “static” keyword, unless inline isn’t supported:

#if defined(_MSC_VER)

#define Py_INLINE(type) __inline type

#elif defined(USE_INLINE)

#define Py_INLINE(type) inline type

#else

#define Py_INLINE(type) static type

#endif

The only question is with the last line.  How many platforms actually _do_not_ have inlines?  Would writing stuff like this be considered problematic for those platforms?  Note, that I’m not suggesting replacing macros all over the place, only for new code.

Another question is:  Is “static inline” in any practical way different from “inline”?

It would be great to get rid of macros in code. It would be great for debugging too!

K