31–40 of 90 posts
I've used Swig to inherit from base classes in Java to implementations in C++. Swig generated the JNI and C++ bindings. Fun times.
Curious of the different reasons reasons people are creating Python bindings. Was it because the project started in Python, then when performance became an issue the slow parts were rewritten in C++. Or it started in C++ and Python bindings were added later.
I've used Swig for C++ to Python interop and let me warn you it is a nightmare. The syntax is absurdly terse and convoluted, documentation sucks and good luck trying to search the web for constructs made only of special characters. CLIF is way nicer for C++/Python. If you need other languages then best of luck (Zig, Rust and D are easier than Java and Go at least).
Curious of the different reasons reasons people are creating Python bindings. Was it because the project started in Python, then when performance became an issue the slow parts were rewritten in C++. Or it started in C++ and Python bindings were added later.
I don't think this is the right way: interop with the C ABI, and for the hercules who want to do that with c++, should be native to such programming languages, not from a project on the side.
Agreed. And I think approaches like python or node, where you need to write some c code against their API, is getting it wrong also. The most smooth interop experience I've ever had is with c#. You just export normal c functions from a dll, and the c# code can call it. All the awkward bits like "how do I marshal a string" happens in the host code, not the native module. The overall experience of that is soooo much be…
Curious of the different reasons reasons people are creating Python bindings. Was it because the project started in Python, then when performance became an issue the slow parts were rewritten in C++. Or it started in C++ and Python bindings were added later.
I don't think this is the right way: interop with the C ABI, and for the hercules who want to do that with c++, should be native to such programming languages, not from a project on the side.
Agreed. And I think approaches like python or node, where you need to write some c code against their API, is getting it wrong also. The most smooth interop experience I've ever had is with c#. You just export normal c functions from a dll, and the c# code can call it. All the awkward bits like "how do I marshal a string" happens in the host code, not the native module. The overall experience of that is soooo much be…
I've used Swig for C++ to Python interop and let me warn you it is a nightmare. The syntax is absurdly terse and convoluted, documentation sucks and good luck trying to search the web for constructs made only of special characters. CLIF is way nicer for C++/Python. If you need other languages then best of luck (Zig, Rust and D are easier than Java and Go at least).
In my personal experience, to use a very small C library in python in a work project, my life became simpler when I ditched swig and just called the C API from python. Then I had a pure python codebase that I could run on any python version without recompilation, and I no longer had the complication of having to deal with swig's different versions across different distribution releases. For much bigger projects I cou…
How do you call C API from python? Through executable + stdin/stdout?
When you have a lot of C functions to call, having to duplicate all the declarations in Python code gets old. That's where the third-party cffi module comes in. It can parse straightforward C headers and use the appropriate types automatically. However, for complex headers (lots of macros, for example), it has to run a C compiler, which requires the machine which will run the script to have a functioning C toolchain. When using cffi, it can also be pretty easy to crash the interpreter with a use-after-free bug.
If you're already invested in the Cython ecosystem, you can use that for calling into C too. However, getting into Cython just to call a few C functions would be cracking a nut with a sledgehammer.
Finally, the nuclear option is to write a C extension module. Extension modules receive unconverted Python objects directly and can deeply integrate with the CPython interpreter. However, they also need to be compiled for a specific version of CPython, and won't necessarily work in alternative Python implementations. If you can get the job done with ctypes or cffi, you should avoid extension modules.