I'm seeing this phenomenon in my own work. I do a fair amount of computational stuff (in the old sense of computing something, as opposed to just using a computer), and I find myself gravitating more & more to Python.
Performance is, of course, an issue. But in one case I noted that the week or so it took me to write and execute some Python code was almost certainly less time than it would have taken just to write the code in C/C++. I concluded that -- for this problem at least -- the extra performance I might have gotten out of C++ simply did not matter.
However, these days I do not do much with large scientific models or anything resembling big data. Performance is not the issue for me that it would be for others. And with articles having titles like "Why Python is Slow: Looking under the Hood"[1] out there, I find it difficult to see how Python can displace Fortran (or maybe C) in the realm of traditional supercomputing.
remember there are ways to squeeze performance out of python, projects like cython for example. you can also make a python library in C... I don't know how practical it is though
If you have a C function, calling it from python is trivial. It even has great support for passing numpy arrays to functions that expect C arrays, and taking C arrays and treating the like numpy arrays.
I use ctypes with numpy.ctypeslib. The end results aren't as robust as 'real' python extensions (you have keep track of types yourself and write your own python wrappers), but it is much quicker and easier to get started. You don't have to learn anything about the python API, your C code remains 'pure' since it doesn't have to know anything about python and there is almost no boilerplate.
For simple one off bindings to C functions it's great, especially if the data you're passing back and forth are numpy arrays.
There is also CFFI, which I haven't really used, but lots of people seem to like it.
Comments
I'm seeing this phenomenon in my own work. I do a fair amount of computational stuff (in the old sense of computing something, as opposed to just using a computer), and I find myself gravitating more & more to Python.
Performance is, of course, an issue. But in one case I noted that the week or so it took me to write and execute some Python code was almost certainly less time than it would have taken just to write the code in C/C++. I concluded that -- for this problem at least -- the extra performance I might have gotten out of C++ simply did not matter.
However, these days I do not do much with large scientific models or anything resembling big data. Performance is not the issue for me that it would be for others. And with articles having titles like "Why Python is Slow: Looking under the Hood"[1] out there, I find it difficult to see how Python can displace Fortran (or maybe C) in the realm of traditional supercomputing.
[1] https://jakevdp.github.io/blog/2014/05/09/why-python-is-slow...
remember there are ways to squeeze performance out of python, projects like cython for example. you can also make a python library in C... I don't know how practical it is though
If you have a C function, calling it from python is trivial. It even has great support for passing numpy arrays to functions that expect C arrays, and taking C arrays and treating the like numpy arrays.
with this ?
https://docs.python.org/2/extending/extending.html
I use ctypes with numpy.ctypeslib. The end results aren't as robust as 'real' python extensions (you have keep track of types yourself and write your own python wrappers), but it is much quicker and easier to get started. You don't have to learn anything about the python API, your C code remains 'pure' since it doesn't have to know anything about python and there is almost no boilerplate. For simple one off bindings to C functions it's great, especially if the data you're passing back and forth are numpy arrays.
There is also CFFI, which I haven't really used, but lots of people seem to like it.