I often use C++ and pybind11 to do this. pybind11 takes an approach very similar to boost::python (template magic). It works rather well.
Though most of the C code I write can compile as C++ also.
Why write in C then? It's still the lingua franca in microcontroller land... Just want to reuse the code on PC and Embedded Linux, and Python makes high-level testing much nicer.
Pretty much this. Add to that pybind11's exceptional numpy compatibility (including easily mapping C types to structured numpy dtypes that can be e.g. converted to a dataframe), and there's not many choices left if you're not planning on reinventing a wheel or two.
Both pybind11 and boost::python involve writing code. This solution doesn't, save for listing the names of the files to be made available to Python (or C#, or Excel, or...).
Neither ctypes nor cffi involves writing glue code. In fact you don’t even need another source file, let alone a whole other language toolchain (wait, you actually need two other source files plus your third-party dpp library).
I'm not sure I understand your comment. Someone said they use pybind11, someone responded to that by saying pybind11 requires writing code, and you responded by saying ctypes and cffi don't.
OP presents their solution as an “easy” solution that doesn’t require glue code. Except there are already established native solutions that actually don’t require glue code.
Sure, I’ll be more specific: there’s no glue code for function calls. Whatever function you want to call doesn’t need to be declared up front, you just call it at runtime, and it’s looked up dynamically. However, data structures like arrays and structs need to be declared, if needed.
Comments
I often use C++ and pybind11 to do this. pybind11 takes an approach very similar to boost::python (template magic). It works rather well.
Though most of the C code I write can compile as C++ also. Why write in C then? It's still the lingua franca in microcontroller land... Just want to reuse the code on PC and Embedded Linux, and Python makes high-level testing much nicer.
Pretty much this. Add to that pybind11's exceptional numpy compatibility (including easily mapping C types to structured numpy dtypes that can be e.g. converted to a dataframe), and there's not many choices left if you're not planning on reinventing a wheel or two.
(disclaimer: pybind11 contributor)
Is pybind numpy aware? This is interesting. Having never used pybind, where can I learn more?
Both pybind11 and boost::python involve writing code. This solution doesn't, save for listing the names of the files to be made available to Python (or C#, or Excel, or...).
Neither ctypes nor cffi involves writing glue code. In fact you don’t even need another source file, let alone a whole other language toolchain (wait, you actually need two other source files plus your third-party dpp library).
I'm not sure I understand your comment. Someone said they use pybind11, someone responded to that by saying pybind11 requires writing code, and you responded by saying ctypes and cffi don't.
How is that relevant to a discussion of pybind11?
OP presents their solution as an “easy” solution that doesn’t require glue code. Except there are already established native solutions that actually don’t require glue code.
In what sense does ctypes not require writing glue code?
Sure, I’ll be more specific: there’s no glue code for function calls. Whatever function you want to call doesn’t need to be declared up front, you just call it at runtime, and it’s looked up dynamically. However, data structures like arrays and structs need to be declared, if needed.
So... ctypes requires writing glue code. The solution in the article doesn't.
"if needed" means "needed with any and all C APIs one would be interested in".