I agree for Fortran code that is relatively clean and without clear issues. special is its own beast though. Much of the code in specfun.f is clearly of very low quality. The Fortran implementation of hyp2f1 had many outstanding issues which were never fixed due to the difficulty of working with and reviewing the dense Fortran code. With the Cython implementation, I was able to clean up issues that were open for nearly 5 years. The other hypergeometric functions also have many problems and I plan to replace these as well. I haven’t looked into anything beyond hypergeometric functions though. Perhaps many of these are already OK.
Please compare the new Cython implementation with the old Fortran implementation before judging whether this was a step in the wrong direction. See also the suite of benchmarks that I wrote at special/_precompute/hyp2f1_data.py (unfortunately I’m only able to post 2 links).
Automatic code generation seems like a great idea for old Fortran which is already at production grade, but this isn’t true for much of specfun.f. Perhaps no one can promise perfectly bug-free code, but I can almost guarantee that the new code will be an improvement for these particular cases.
The impetus for rewriting here wasn’t to remove Fortran for the sake of it, but because much of specfun.f is a bug riddled mess which probably shouldn’t be trusted in production code. When I initially inquired about fixing hyp2f1, I was asked to use Cython for ease of review and maintenance. If there were consensus around using something like C++ instead, I think I could handle that, but it would likely slow down the pace of development.