Le ven. 7 sept. 2018 à 12:45, M.-A. Lemburg <mal@egenix.com> a écrit :

On 07.09.2018 11:46, Victor Stinner wrote:

...

I'm trying to remove functions from the C API which allow to do things which are not possible at the Python level: https://pythoncapi.readthedocs.io/bad_api.html#no-public-c-functions-if-it-c...

It's a request coming from PyPy developers.

There are always things which you have to be able to do at the C level but cannot do at the Python level and that's intentional, since you're working at the C level and want to have direct access to the data, avoiding copying things around all the time and creating intermediate temporary objects or buffers for this.

Your motivation here is basically performance, am I right?

From what I understood, such optimization in the short term becomes a high technical debt in the long term for PyPy, Gilectomy, and any other Python implementation.

Inside CPython, the core and builtin modules, micro-optimizations must be used: abuse borrowed references, macros, access directly to all fields of C structure, etc.

But here I'm talking about the public C API used by third party extensions.

... Sadly, I didn't work on this topic yet, so I would prefer to not go further in the discussion, since I have no concrete examples of issue :-)

You also want callbacks to work from both worlds (Python into C and C into Python), or embed the interpreter, or provide new ways of working with the existing objects, or work with code in a way which bypasses the exception machinery (in C you very often raise exceptions and catch them without the exception object itself every being created).

You should really replace "Python" (the language) with "CPython" in your paragraph. I would like to move away from the current CPython.

Victor