[Python-Dev] Making PyInterpreterState an opaque type

Victor Stinner vstinner at redhat.com
Thu Feb 21 06:13:51 EST 2019

Le mar. 19 févr. 2019 à 21:15, Stefan Behnel <stefan_ml at behnel.de> a écrit :
> What I would ask, though, and I think that's also Jeroen's request, is to
> be careful what you lock up behind Py_BUILD_CORE. Any new functionality
> should be available to extension modules by default, unless there is a good
> reason why it should remain internal. Usually, there is a reason why this
> functionality was added, and I doubt that there are many cases where these
> reasons are entirely internal to CPython.

I think that we should have some rules here.

One rule is that we should avoid APIs which allow to do something no
possible in Python. That's an important rule for PyPy and other Python
implementations. We cannot avoid such APIs completely, but they should
be the exception, not the default.

Another rule is to avoid stop adding new APIs which only exist for
performance. For example, PyDict_GetItem() only exists for
performance: PyObject_GetItem() can be used instead. There are
multiple issues with writing "specialized code". For example,
PyDict_GetItem() must only used if the type is exactly dict
(PyDict_CheckExact). Otherwise, you change the Python semantics (don't
respect overriden __getitem__). Each new API means more work for other
Python implementations, but also more maintenance work for CPython.

Premature optimization is the root of all evil. Most C extensions use
premature optimization which are causing us a lot of troubles nowadays
when we want to make the C API evolve and cause issues to PyPy which
has issues to reimplement the C API on top of their different object
model with a different GC.

These are just proposals. Feel free to comment :-)

Night gathers, and now my watch begins. It shall not end until my death.

More information about the Python-Dev mailing list