On 31 July 2018 at 17:45, Antoine Pitrou email@example.com wrote:
On Tue, 31 Jul 2018 09:27:03 +0200 Jeroen Demeyer J.Demeyer@UGent.be wrote:
On 2018-07-31 08:58, Antoine Pitrou wrote:
I think Stefan is right that we should push people towards Cython and alternatives, rather than direct use of the C API (which people often fail to use correctly, in my experience).
I know this probably isn't the correct place to bring it up, but I'm sure that CPython itself could benefit from using Cython. For example, most of the C extensions in Modules/ could be written in Cython.
We don't depend on any third-party Python modules. Adding a Cython dependency for CPython development would be a tough sell.
Also, a C extension can be built-in (linked statically into the interpreter), which I think would be hard to do with Cython.
It'd be *really* nice to at least be able to write some of the C API tests directly in Cython rather than having to fiddle about with splitting the test between the regrtest parts that actually define the test case and the extension module parts that expose the interfaces that we want to test.
So just as we have a split between the core interpreter components needed to freeze importlib and the full Python interpreter, it could be very interesting to have a split between the builtin and extension modules that are required to bootstrap Cython, and those that can instead *rely* on Cython as part of their build process.
While actually doing that would likely mean introducing a venv dependency into the later stages of the build process, we already have such a dependency for the docs build, and that seems to work OK.
P.S. Note that even though static linking Cython generated modules with CPython doesn't work right just now, experiments like https://mdqinc.com/blog/2011/08/statically-linking-python-with-cython-genera... suggest that it shouldn't take too many adjustments to the build process to get it to work by default.