Strange, AppVeyor seems stuck: " continuous-integration/appveyor/pr Expected — Waiting for status to be reported ". I will close/reopen the issue to schedule a new job.

My PR #10079 adds a new Py_STATIC_INLINE() macro. I will wait until the other PR is merged to be able to use Py_STATIC_INLINE() in this PR.

Ok, I merged PR #10093 which adds Py_STATIC_INLINE(). I rebased this PR on top of it and I modified this PR to use Py_STATIC_INLINE().

I also chose to remove the NEWS entry.

@methane: Would you mind to review it?

Doesn't this break many third party modules which use PyObject_INIT()?

Doesn't this break many third party modules which use PyObject_INIT()?

I don't know how to test that. Which kind of failure do you expect?

According to the CPython code base, the main annoyance is the introduction of a cast warning because the macros now require a strict type: PyObject* and PyVarObject*.

If you consider that we must no force all C extensions author to fix their code, I can add a macro which does the cast for them.

First I wanted to remove the return value, since I don't see the point. But inside CPython, a lot of code rely on the return value. So I decided to keep it to reduce the annoyance... and avoid breaking code.

Which kind of failure do you expect?

You have added some (PyObject*) cast in caller.
I expect same fix is required for third party extensions.

One option to avoid it is using void* as first argument and cast it to PyObject* in the function.
But it kills one of the merits of inline function over macros.

I expect same fix is required for third party extensions.

Right. Do you consider that it's an issue? It's just a compiler warning. IMHO it's a good thing that developers cast explicitly, no? A function (macro currently) which accepts any type is just weird.

If you prefer, I can rename the macro to _PyObject_INIT() and add:

#define PyObject_INIT(obj) _PyObject_INIT((PyObjcet *)(obj))

So the "function" accepts any type, as your void* suggestion.

@methane: what do you think?

Right. Do you consider that it's an issue? It's just a compiler warning.

I expected it cause compile error, not warning.
I prefer current, simple and clean solution.

I expected it cause compile error, not warning.

It only causes the compilation to fail if you use -Werror. Very few people use this option, and if they use it, they are well aware of the effect of the flag :-)

I prefer current, simple and clean solution.

If too many users complain, we can add the macro doing the cast later. Even after the 3.8.0 release.