Types from Fortran to Python via Opaque Pointers

No. This is simply not true. Let me put this in a simpler context. Since shared libraries cannot be built and uploaded to PyPI (without going through actually writing Python-C code / the auditwheel process etc. see cibuildwheel for more information), there will never be a pip install version of a library which interfaces through ctypes which means as far as fortran in python as far as the Python ecosystem is concerned it is a non-starter.

Yet gfort2py works without any modification to the source (so no annotations and no limitations on intent). A user of gfort2py doesn’t even need to know ctypes is, it’s entirely wrapped and transparent to the user.

For fortran programmers who want to provide Python bindings, ctypes will be fine. Along with the note from the readme about LD_LIBRARY_PATH.

For more of an understanding of these issues there is the post on SciPy’s build system issues, and the simple matter that as it stands, no user ever needs to compile SciPy’s fortran code themselves, they get it in a binary wheel, which gfort2py cannot do because of a ctypes limitation.

Note that you can build a local wheel and distribute (with a prayer that all the system dependencies are the same) it but it needs to be “compatible” (via cibuildwheel typically) for PyPI distribution.

The limitation has been listed earlier as well, users need to have the library (either the .dll or the .so) at runtime, and this path needs to be correctly set for every new library. This is in sharp contrast to the wheel approach where python handles this automagically.

When was the last time a pip install required setting an environment variable? There are simply very different expectations for different communities. Fortran programmers are expected to handle their libraries themselves, and the wrappers, Python users are largely not.

I have 8 lines of code in gfort2py that care about the OS (and that’s just for selecting the extension for shared libraries).

Compared to the 0 lines needed from having actual C-Python code. I’m not saying it is too hard to support and gfort2py is excellent work. However, we have differing veiws on what counts as portable. Portability is not the same as popularity or ease. That it is simple to have gfortran only doesn’t make it acceptable for cases like scipy or the rest of the Python community, no matter how useful and elegant it is for the fortran programmers who use only gfortran.

I do want to be clear about the fact that gfort2py is a good project with clear goals and does the Fortran community a lot of good. However, ignoring the real reasons why it is not acceptable for more general use is also not a great attitude.

Another point is closer to the compiler issue. As noted here: https://fortran-lang.discourse.group/t/the-difficulties-of-using-fortran-in-scipy/

One of the main issues is the lack of compatible Fortran compilers. This means that gfortran on Windows depending on where it comes from will be unable to link correctly to the C libraries… but this is an issue with compiling the library… until you try to share the .dll file with someone else and they can’t find symbols because their gfortran is different…

It is however impossible to describe the problems of portability like this. A practical example as mentioned, is to see if it is possible to get a pip install friendly binding + library out of this method, and then to see if it can be reliably built across the ~53 different configurations NumPy supports.