- This question is republished from SO at the suggestion of the SO user to put it here since there is no specific code in question.
- This question is a subset of my broader topic of Fortran modernization.
- There are already helpful versions of this question (1, 2, 3) and blog posts, and while they are helpful, I'm curious what the best practice is now (some of those posts are 5-10 years old) and the context of my situation, which is why it is asked in a similar way.
Our current code base is largely Fortran (400K LOC, mostly F90 / some F77 / maybe some newer versions), scattered among some 10 separate (organizationally) development teams in (somewhat) separate modules.
We are exploring the best practice idea of taking one of those modules and writing it in a faster development language (Python), and wrapping and extending bottlenecks in Fortran.
However, since the module is currently fully in Fortran and interacts with other Fortran modules and a main Fortran loop, we must keep the appearance or interface of the module with the main Fortran loop the same.
So the incremental change approach for this Fortran module, and other Fortran modules of similar architecture, is to keep the interfaces the same and change the internal parts.
In other words, the shell or signature of the Fortran subroutines or functions would not change, but the functionality within the function would be changed.
This functionality within the function is what we want to rewrite in Python.
From the online discussions, and from my intuition, whatever is worth it seems inadvisable to embed Python in this way, and instead do the opposite: extend Python with Fortran (for bottlenecks as needed).
However, this embedded Python approach seems like the only logical, smaller, and more atomic step forward to isolate changes to the larger Fortran system.
There seem to be a few options for this Python embedding issue.
The most stable and future proof way is through ISO_C_BINDING and using the Python C API (in theory …).
There are also stable solutions through Cython and perhaps ctypes that are reliable and well maintained.
There are more dependency-dependent approaches, such as cffi and forpy, that introduce complexity for the benefit of not writing the extra C interface code.
We are also aware of simple Python scripting calls from Fortran, but these seem to be too heavy on write / read to disk; We would really like to do minimal read / write to disk and keep the array passing in memory (hopefully only the pointer locations were passed, not the array copies).
Another restriction is that this Fortran-Python interface should be able to handle the most common data types and structures, including multi-dimensional arrays, or at least have a way to decompose complex custom data types into some collection of simpler data types. , like strings and arrays.
Given the description above, do you have any advice on what are the best practices currently available for calling Python (or other similar flexible language) from Fortran (for example using 2003 or 2008 versions; I'm not sure if all the features from 2018 are implemented in our Intel Fortran compiler)?