Personally I like pybind11 much better, it is incredibly easy to wrap even fairly complex c++ (and by extension c) projects with it. The best thing about it is its very good and thorough documentation. It is even fairly simple to autogenerate most of those bindings using libclang (The example he gave fall in that category, it gets trickier if you want to be able to subclass in python).
Interfacing Python and C: Advanced “ctypes” Features
11–18 of 18 posts
Re: Interfacing Python and C: Advanced “ctypes” Features
#12why not rust? much simpler and safer with libs like https://github.com/PyO3/pyo3
Because the library you are trying to use it is written in C / C++, which is more likely than that is written in rust.
Re: Interfacing Python and C: Advanced “ctypes” Features
#13why not rust? much simpler and safer with libs like https://github.com/PyO3/pyo3
I might be wrong, but it seems PyO3 is more for going from Rust to Python, versus ctypes being for Python to C.
Sure, coupes is fine if do not need to write anything and ctypes is enough. But as soon as you need to make c to python bridge it safer to do in rust. Pyo3 handles ref counting and Gil management for you
Re: Interfacing Python and C: Advanced “ctypes” Features
#14Personally, I prefer cython most of the times to write C binding/lib. All Gil helpers are very useful.
Re: Interfacing Python and C: Advanced “ctypes” Features
#15Why would you use CTypes instead of CFFI?
It's in the standard library and doesn't require having the whole C toolchain available and working (non-trivial if you're not talking about standard things in /usr/{include,lib}).
If all you need is a simple interface to a couple of functions and you want portability across system variants, that might be the path of least resistance and the performance is often negligible if the amount of work being done in the C code is significant.
Re: Interfacing Python and C: Advanced “ctypes” Features
#16Earlier quoted context omitted.
I might be wrong, but it seems PyO3 is more for going from Rust to Python, versus ctypes being for Python to C.
Sure, coupes is fine if do not need to write anything and ctypes is enough. But as soon as you need to make c to python bridge it safer to do in rust. Pyo3 handles ref counting and Gil management for you
That sounds like the opposite direction: ctypes is for when you have a Python program which wants to call a C library, not when you want C code to call Python. As a concrete example, I work with JPEG 2000 imagery. I use ctypes so Python programs can load an image using a JP2 codec such as OpenJPEG to decode the image and save image tiles. Given the complexity of OpenJPEG, it would be a major project to port it to any other language and since it does a massive amount of computation the overhead of ctypes calling it is a small rounding error in the total processing time.
Unless the PyO3 documentation is completely leaving out a major application, it doesn't support this scenario.
Re: Interfacing Python and C: Advanced “ctypes” Features
#17pybind11 is the nicest foreign function interface I've encountered:
Re: Interfacing Python and C: Advanced “ctypes” Features
#18Earlier quoted context omitted.
Sure, coupes is fine if do not need to write anything and ctypes is enough. But as soon as you need to make c to python bridge it safer to do in rust. Pyo3 handles ref counting and Gil management for you
That sounds like the opposite direction: ctypes is for when you have a Python program which wants to call a C library, not when you want C code to call Python. As a concrete example, I work with JPEG 2000 imagery. I use ctypes so Python programs can load an image using a JP2 codec such as OpenJPEG to decode the image and save image tiles. Given the complexity of OpenJPEG, it would be a major project to port it to any…
Pyo3 support both. You can expose rust to python, and would look to python as native functions and classes or you can call python code from rust
Pyo3 uses rust refs ownership to enforce proper Gil usage. You code won’t compile if you use Gil in wrong way