Banner added to all pages (the gray note):

Link to this new section:

I think we'll need a bit more nuance in here, explaining why we still have a C API at all if we're telling people not to use it (obvious to us, not obvious to someone who happens to be reading these docs for the first time).

I think we'll need a bit more nuance in here, explaining why we still have a C API at all if we're telling people not to use it (obvious to us, not obvious to someone who happens to be reading these docs for the first time).

Totally agree. For example, I've personally taken a lot of information from the last discuss thread. It seems to be very useful to document these nuances in concise manner.

I also think we need to be careful to indicate that these are not supported by the same people who maintain Python, and issues need to be raised with the projects directly.

...and, by implication, other abstractions arenot recommended?

@zooba: I elaborated the rationale a little bit in the "Recommended third party tools" section. Feel free to propose better wording, I'm not good to write documentation :-)

https://cpython-previews--133679.org.readthedocs.build/en/133679/c-api/intro.html#recommended-third-party-tools

...and, by implication, other abstractions are not recommended?

It's not the case. Did I miss some major abstractions in my list?

The list is at least inconsistent withhttps://docs.python.org/dev/faq/extending.html#writing-c-is-hard-are-there-any-alternatives

However my problem is with the wordrecommended which implies some sort of official blessing which would put new (possibly better) abstractions at a disadvantage and implies some quality control process. I'd prefer something likeestablished orcommonly used.

However my problem is with the wordrecommended which implies some sort of official blessing which would put new (possibly better) abstractions at a disadvantage and implies some quality control process.

IMO, this is actually arecommended API for the most of the projects. There is no direct implication that other abstraction could not be better in future. In fact, it's not a problem to add a new entry to this list, if some project had proven as a well-established alternative.

But at the moment a maintainer of some project can use C API directly or through some binding. And CPython developers encourage that maintainer to use the latter.

@encukou isagainst the banner, so I wrote a simpler PR just to add a section to the C API Introduction, and modify existing text to point to this section:#134526.