[capi-sig]No C API if it's not doable in Python
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
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...
Sorry – no way. Cython can definitely make very good use of those internals, shortcuts, and what not. If you want them removed, then please replace them with something equivalent that doesn't reduce the performance.
Stefan
- Stefan Behnel wrote:
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-can-t-be-done-in-python
Sorry – no way. Cython can definitely make very good use of those internals, shortcuts, and what not. If you want them removed, then please replace them with something equivalent that doesn't reduce the performance.
Just to concur: This argument is not restricted to Cython :-)
Also I don't see the point, really. CPython is Cpython and Pypy is Pypy (and *Py is *Py). I dive into C for 3 reasons: 1) Performance, 2) Wrapping of C libraries and 3) doing stuff I can't in python (it's called "extension" after all). And I just use the python implementation which is suitable for my needs. CPython suits very well most of the time.
This discussion might also be tackled from the other side: Maybe some things *should* be made available in python instead.
Cheers,
I have tried using ErrorDocument 401, but doesn't work. ^^^^^^^^^^^^^ Oh dear. What does it do - lounge around on the couch all day drinking beer and watching TV? -- "Kash" und Alan J. Flavell in ciwsu
My plan for Cython is to provide the full C API, the API used by CPython core and builtin modules. But it should be an opt-in option, rather than the default, as we do currently.
At the ABI level, I'm not sure if we can hide some functions for regular C extensions, but only give access to Cython? Maybe the names should be mangled to make sure that no mistake is done? For *example*, keep PyTuple_GetItem() function available, but as a different symbol like: _PyTuple_GetItem()?
For the consumer of the C API, the cost of using the full C API is to loose the stable ABI and have to adapt the code for each Python release (3.x)... Well, exactly what we do have currently.
Obviously, Cython is heavily tied to CPython internals. If CPython internals evolve to implement some optimizations, Cython will be broken. But I prefer to see what's going on, rather than making an assumptions.
Note: My goal is not to kill Cython :-) Working Cython and numpy is an important target for me.
Victor Le ven. 7 sept. 2018 à 15:09, Stefan Behnel python_capi@behnel.de 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...
Sorry – no way. Cython can definitely make very good use of those internals, shortcuts, and what not. If you want them removed, then please replace them with something equivalent that doesn't reduce the performance.
Stefan
capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org
participants (3)
-
André Malo -
Stefan Behnel -
Victor Stinner