It still is, and Cython is great for accelerating critical Python code.
A C extension is far preferable when you want to code in C, either to write a new data type[1], or write a Python frontend to a C library[2] that is too complex to be well supported by simple FFI.
I think people use Cython more internally when they value the maintainability of "mostly Python" over the fact that it's slower than what native C would get them.
> over the fact that it's slower than what native C would get them.
You have a quote for that? Cython code, in the context of "C-extended-python" probably never is slower than native C. There has been a lot of work over the years to make sure of that.
Now, if you want to compare it to "a C program/library in the wild", then we are not comparing apples to apples. The whole point of Cython is inserting C code into a Python module, to have (high performance) C code inside a Python environment.
My source is simply running `cython -a` to see all the highlighted lines, and fixing them and observing how many hoops I have to jump through to get code that doesn't interact with the interpreter.
Cython makes you do more work to avoid the interpreter. C makes you do more work to involve the interpreter.
> There has been a lot of work over the years to make sure of that.
Some cython code can compile close to the C code you'd write.
But that's not how it's likely to be used, because the design pushes you in the opposite direction by default, and the value of Cython is that it's far faster than vanilla Python, and the painless interop.
It's not a "benefit over" thing, they're tools operating at completely different levels and thus not necessarily exclusive.
cython binds to the C API of CPython, meaning you've got the same problem loading a cython-compiled extension into alternative implementations as you have with other CPython extensions.
If HPy succeeds, cpython can (hopefully) have an HPy backend and generate HPy bindings, somewhat transparently.
