21–30 of 90 posts
Now days unless it is required for performance I doing up grpc to handle library calls. I’m that lazy. Lazier than a node developer that imports the world for a hello world health check.
Earlier quoted context omitted.
How do you call C API from python? Through executable + stdin/stdout?
https://docs.python.org/3/library/ctypes.html
Using a subprocess and pipes wouldn't work with a .so file. I'd need to write a C wrapper to implement a way to call functions and marshall parameters in binary…
Basically CORBA over a pipe rather than a socket!
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).
More than a nightmare, just look at their website.
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).
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?
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).
See https://projects.om-office.de/frans/swig_demo/-/tree/master/... (disclaimer: very old and special exception handling)
IMHO this is a good practice anyway, because this way you make sure, your API looks the same in every binding.
And this way you get a binding for Python, Java, JavaScript, C#, Lua, and much more
There is also gobject-introspection[0], which is also capable to generate bindings for quite a lot of higher level languages from (gobject based) c-code. I'm always impressed on how simple it is to use an object I defined in c within python. [0]: https://gitlab.gnome.org/GNOME/gobject-introspection
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).
I took different approach. Because I only needed to support these two languages, there’s no separate interface definition language, and no code generator for interfaces. Instead, users are expected to write both language projections manually.
Then there’s a runtime code generator on the .NET side of the interop which builds runtime callable proxy types for interfaces implemented in C++, also virtual tables for C# objects consumed by C++.