I'm currently working on a project using Cython to wrap and expose a large and complex C API (CEF) to Python. One of the most time-consuming, tedious, and error prone tasks is translating functions and structures to Cython syntax, including managing the GIL. Also, keeping the translated API up to date with new releases.
I'm curious to see how this D approach compares, both in workload required to expose and use an API, and the flexibility of the end result. There are a lot of quirks and special syntaxes in Cython to allow for not just interop between C and Python, but also writing C in Python-like syntax mixed with actual Python. This is an area I assume this approach would be lacking.
Regardless, as someone who loves mixing C and Python, this is an encouraging reason to look more at D.
Can you clarify your question? I'm using Cython to write extension modules that directly interface with CEF's C API. CEF is about 40k lines of C++ that programmatically controls Chromium, which itself is written in C and C++.
Email me at fred(underscore)weigel(at)hotmail(dot)com
I interfaced CEF to Java in 2000 lines of C++
Simple, easy API. I run CEF in a separate process, and use
the Window manager (Linux and Windows) to cause the Chrome
windows to overlay the application windows. Standard pipes
are used between the controlling process and CEF.
Email me if you are interested. As a ps -- I can use CEF from shell scripts as well. Anything with a C FFI works.
I see. Thanks, that does change my understanding of your situation. My revised question with your clarifications in mind is, is there a reason you're not calling CEF's C api directly from Python? Are your extension modules doing some heavy lifting themselves, or are you using Cython just to handle the glue between the language interface?
is there a reason you're not calling CEF's C api directly from Python?
Such as by using CFFI? Cython's strength, in my opinion, is in the fact that it is its own language resembling both C and Python that compiles to down to C, rather than just an FFI.
Are your extension modules doing some heavy lifting themselves, or are you using Cython just to handle the glue between the language interface?
I would say the majority of the application logic is written in plain Python, and Cython makes interfacing with it, creating higher level interfaces, and marshaling data far easier than with CFFI or using the C API directly. This is pretty subjective though.
Comments
I'm currently working on a project using Cython to wrap and expose a large and complex C API (CEF) to Python. One of the most time-consuming, tedious, and error prone tasks is translating functions and structures to Cython syntax, including managing the GIL. Also, keeping the translated API up to date with new releases.
I'm curious to see how this D approach compares, both in workload required to expose and use an API, and the flexibility of the end result. There are a lot of quirks and special syntaxes in Cython to allow for not just interop between C and Python, but also writing C in Python-like syntax mixed with actual Python. This is an area I assume this approach would be lacking.
Regardless, as someone who loves mixing C and Python, this is an encouraging reason to look more at D.
Is there a reason you chose not to build / refactor the project as a library to call from Python?
Can you clarify your question? I'm using Cython to write extension modules that directly interface with CEF's C API. CEF is about 40k lines of C++ that programmatically controls Chromium, which itself is written in C and C++.
Email me at fred(underscore)weigel(at)hotmail(dot)com
I interfaced CEF to Java in 2000 lines of C++
Simple, easy API. I run CEF in a separate process, and use the Window manager (Linux and Windows) to cause the Chrome windows to overlay the application windows. Standard pipes are used between the controlling process and CEF.
Email me if you are interested. As a ps -- I can use CEF from shell scripts as well. Anything with a C FFI works.
FredW
I see. Thanks, that does change my understanding of your situation. My revised question with your clarifications in mind is, is there a reason you're not calling CEF's C api directly from Python? Are your extension modules doing some heavy lifting themselves, or are you using Cython just to handle the glue between the language interface?
Such as by using CFFI? Cython's strength, in my opinion, is in the fact that it is its own language resembling both C and Python that compiles to down to C, rather than just an FFI.
I would say the majority of the application logic is written in plain Python, and Cython makes interfacing with it, creating higher level interfaces, and marshaling data far easier than with CFFI or using the C API directly. This is pretty subjective though.
This D approach is essentially cffi. With another compiler thrown in for fun.