> I think the rules for C includes are that `"path/header.h"` looks next to the current file first, whereas `<path/header.h>` looks only in include directories.

Oh ok, thanks.


> However, given your technique of mostly hiding the new directory name from API consumers, what do you think of calling the new directory "cpython" rather than "unstable"?

I'm not comfortable with "CPython" name. For me, everything the "CPython C API" is the concatenation of all files in Include/ but also in subdirectories. Right now, it's unclear what is the "Python" API ("portable" API, without implemenetation details) vs the "CPython API" (implementation details).

"unstable" comes from the PEP 384: "Defining a Stable ABI". IMHO what is not in the "Stable ABI" is the "Unstable ABI". By extension, APIs excluded by Py_LIMITED_API make the "unstable API".

From my point of view, "CPython API" would be more internal/ + unstable/ APIs.


> The idea there would be that the "unstable ABI" eventually become known as "the CPython C API" (since it exposes a lot of CPython implementation details", while the limited API could become known as "the portable cross-implementation Python C API".

Everybody seems to be confused by what is the "Python C API"... I see even more confusion if we have a "CPython C API". Do you see? "CPython" vs "Python", "Python C" vs "CPython"...

IMHO "unstable" is more explicit :-) It means: "don't touch this" :-D