4 ms·

Cython is a fantastic and underrated language. It basically allows you to write C using Python syntax, and to also write Python in the same source file. Basical

Cython is a fantastic and underrated language. It basically allows you to write C using Python syntax, and to also write Python in the same source file. Basically if you use a dict or some other nice python functionality, your code will run at Python speed, but if you add a few type annotations and whatnot it runs like C. Not to mention that you can import and use C libraries. Mix and match Python and C as required for the ultimate balance of speed and convenience. It's great.

dom0 9y ago
I disagree (strongly). Cython is nice to save some typing for generating wrappers. It is a very tough language to work with for actually implementing things that you'd want to do in a low-level language, because it's severely underdocumented and underspecified, but extremely complex at the same time. To actually see whether the code as written is correct, one must almost always cythonize it and dig through the generated, verbose and hard to decipher C code. Both the language and the compiler have a ton of things I'd call bugs, induced by the complexities and mismatches in the type system. E.g. it's awkwardly easy to have Cython call some PyObject function on something that isn't a Python object. No thank you. PS: Also avoid using setup.py Extension, including Cython's variant, if you can at all. (Source: I've been maintaining software containing Cython stuff for some while, written and reviewed quite some of it, too.)
- doubleunplussed 9y ago
  I suppose I almost solely use Cython for numerics, which seems to be reliable. Anything that's not numerics is not usually the bottleneck for my code and so is left as Python. So I can't comment on problems trying to use the C end of the Cython continuum as a general purpose replacement for C. For my numerics at least I can't say I've had to dig through generated C. I generate the annotated html to ensure that what I thought would translate to pure C without python API calls indeed has, but I've never had to actually read the C it generates.
  - dom0 9y ago
    The annotated mode is indeed very nice to browse the generated C code, although I still needed to manually read the .c in some cases. The annotated code elides things like the (many thousand lines of) Cython support code; but since few things are documented I sometimes even needed to dig through those, deciphering nested #ifs and whatnot just to see whether the code would be correct. E.g. what does `cdef char *something = somethingelse` give me. Even if you know the type of somethingelse it's at best a guess. (Bonus question: Say you know somethingelse is going to be a Python bytes object. Does something point to a copy?)
- kevin_thibedeau 9y ago
  Cython can wrap libraries but there are better alternatives for doing that. It is of most benefit when doing computation on NumPy arrays. That way you pass in and out native C objects, do bulk computation in compiled code, and never pay the penalty of accessing a PyObject. If you can't guarantee that then there is not much point in using Cython although you still do get a speedup on PyObject code by bypassing the bytecode interp.

dom0 9y ago

I disagree (strongly). Cython is nice to save some typing for generating wrappers. It is a very tough language to work with for actually implementing things that you'd want to do in a low-level language, because it's severely underdocumented and underspecified, but extremely complex at the same time. To actually see whether the code as written is correct, one must almost always cythonize it and dig through the generated, verbose and hard to decipher C code. Both the language and the compiler have a ton of things I'd call bugs, induced by the complexities and mismatches in the type system. E.g. it's awkwardly easy to have Cython call some PyObject function on something that isn't a Python object. No thank you. PS: Also avoid using setup.py Extension, including Cython's variant, if you can at all. (Source: I've been maintaining software containing Cython stuff for some while, written and reviewed quite some of it, too.)

doubleunplussed 9y ago
I suppose I almost solely use Cython for numerics, which seems to be reliable. Anything that's not numerics is not usually the bottleneck for my code and so is left as Python. So I can't comment on problems trying to use the C end of the Cython continuum as a general purpose replacement for C. For my numerics at least I can't say I've had to dig through generated C. I generate the annotated html to ensure that what I thought would translate to pure C without python API calls indeed has, but I've never had to actually read the C it generates.
- dom0 9y ago
  The annotated mode is indeed very nice to browse the generated C code, although I still needed to manually read the .c in some cases. The annotated code elides things like the (many thousand lines of) Cython support code; but since few things are documented I sometimes even needed to dig through those, deciphering nested #ifs and whatnot just to see whether the code would be correct. E.g. what does `cdef char *something = somethingelse` give me. Even if you know the type of somethingelse it's at best a guess. (Bonus question: Say you know somethingelse is going to be a Python bytes object. Does something point to a copy?)
kevin_thibedeau 9y ago
Cython can wrap libraries but there are better alternatives for doing that. It is of most benefit when doing computation on NumPy arrays. That way you pass in and out native C objects, do bulk computation in compiled code, and never pay the penalty of accessing a PyObject. If you can't guarantee that then there is not much point in using Cython although you still do get a speedup on PyObject code by bypassing the bytecode interp.