3 ms·

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

by ben509 6y ago

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. [1]: https://github.com/tobgu/pyrsistent https://github.com/tobgu/pyrsistent [2]: https://github.com/libgit2/pygit2 https://github.com/libgit2/pygit2

throwaway894345 6y ago
> A C extension is far preferable when you want to code in C Or any other language that supports C FFI.
dr_zoidberg 6y ago
> 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.
- ben509 6y ago
  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.
- coldtea 6y ago
  >Cython code, in the context of "C-extended-python" probably never is slower than native C Huh? Cython tries, but it's not exactly optimized hand-coded C. And it works better for some things (e.g. numerical typed code) than others.

by ben509 6y ago

throwaway894345 6y ago

> A C extension is far preferable when you want to code in C Or any other language that supports C FFI.

dr_zoidberg 6y ago

> 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.

ben509 6y ago
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.
coldtea 6y ago
>Cython code, in the context of "C-extended-python" probably never is slower than native C Huh? Cython tries, but it's not exactly optimized hand-coded C. And it works better for some things (e.g. numerical typed code) than others.