add sections on strengths and stakeholers

[iritkatriel]

No description provided.

[vstinner]

LGTM if you fix the few typos and maybe rephase what I pointed out. Overall, it LGTM.

[steve-s]

Would it make sense to expand on other than functional aspects of the API? Extension users may have different requirements regarding stability and necessity to rebuild from sources for different Python versions and interpreters (backwards: will extension compiled on 3.10 work on 3.8, and forwards: will extension compiled today work on 3.15?).

CPython developers, which is maybe a stakeholder that's worth mentioning here (as long as we have not agreed on completely separating API for "the internal interface between CPython's interpreter" and API for Python extensions), do not need to care about stability that much and do not need to care about rebuilding at all, because internal code is rebuilt for each new version by definition. Another difference is the CPython internal code will never be meant to run on alternative Python wheres extension author may see that as an advantage (if it could run on alternative Pythons, more so if it did not require recompiling).

[steve-s]

Thinking about it more, I think the CPython developers section is more than desirable because one of the IMO major issues of the current C API is that the compatibility requirements are holding CPython back from changing its internal implementation.

The Let’s get rid of the stable ABI, but keep the limited API threads comes to mind.

Another example: significant part of the current and the past GIL-removal attempts has been to work around scalability issues with reference counting. And they had to deal with that partly also because reference counting is exposed by the C API, otherwise alternative memory management approach could have been a viable solution.

[iritkatriel]

Yes, good points. Let me merge this and then you can make another PR.