(original) (raw)

In general I support cleaning up our C API to more clearly delineate the boundaries of what people can rely on and what they shouldn't. Could we go farther and do the same separation of the base and limited API at the header level instead of interleaving through #ifndef?

On Sun, Sep 11, 2016, 01:38 Victor Stinner <victor.stinner@gmail.com> wrote:

Hi,

Currently, Python has 3 C API:

\* python core API
\* regular API: subset of the core API
\* stable API (ABI?), the Py\_LIMITED\_API thing: subset of the regular API

For practical purpose, all functions are declared in Include/\*.h.
Basically, Python exposes "everything". There are private functions
which are exported using PyAPI\_FUNC(), whereas they should only be
used inside Python "core". Technically, I'm not sure that we can get
ride of PyAPI\_FUNC() because the stdlib also has extensions which use
a few private functions.

For Python 3.7, I propose that we move all these private functions in
separated header files, maybe Include/private/ or Include/core/, and
not export them as part of the "regular API".

The risk is that too many C extensions rely on all these tiny
"private" functions. Maybe for performance. I don't know.

What do you think?

See also the issue #26900, "Exclude the private API from the stable API":
http://bugs.python.org/issue26900

Victor
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org