STINNER Victor <vstin...@redhat.com> added the comment:
> 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
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
