[python-committers] Call For Participants For The 2016 Python Language Summit

[Victor Stinner]

2016-03-02 2:01 GMT+01:00 Larry Hastings <larry at hastings.org>:
> The purpose of the event is to disseminate information and spark
> conversation among Python core developers.  It's our once-a-year chance to
> get together and hash out where we're going and what we're doing,
> face-to-face.

Sadly, I don't plan to attend Pycon US 2016 (one of the reasons is
that my talk on FAT Python was not accepted, but it's not the only
reason).

But it would be nice if we can open a discussion on the Python C API.
I understood that it's a major blocker issue for PyPy. It's probably
also a major issue for IronPython and Jython. Since Pyston & Pyjion
are based on CPython, it may impact them less, but it's probably still
an annoyance to reach *best* performances.

I would be nice to discuss how to move to a new C API which doesn't
expose implementation details and discuss if libraries will move to it
or not. Implementation "details": GIL, reference counting, C
structures like PyObject, etc.

Sorry, I have no idea how to "abstract" Python objects in such C API.
I have no idea how to design such API.

But I know well that the current C API is too wide, it's almost a
trash where we put everything. There is no clear separation between
functions strictly written to only be used internally, and functions
which are ok to be used outside the CPython code base.

I know that we have a "_Py" prefix for some symbols, but it's more the
exception than the rule. We inherited a giant C API for the old days
of CPython.

The latest major enhancement was the addition of a stable ABI, but the
usage of this API is unclear to me. I'm quite sure that we don't build
our own C extensions of the stdlib using the stable ABI. I also heard
that the stable ABI was broken more than once... So I don't think that
we can say that it's a success...

Sadly, we may conclude that it's not possible to replace the C API, or
that yet another API will not be widely used. Especially if the new
API is only supported by the latest version of Python! A requirement
is probably to be compatible with Python 2.7 and 3.4.

If someone has a more concrete vision of what should be done for the
"Python C API", please organize a session at the Language Summit
and/or open a thread on python-ideas or python-dev.

Victor