No I haven’t tried compiling f2py’s or scipy’s test suite as most of the code isn’t in a module. So I’m not personally interested in supporting it.
Yes a hard dependency on gfortran is both gfort2py’s greatest strength and greatest weakness. Sure I can’t support other compilers on the other hand my life is much simpler as I don’t have to worry about what other compilers are doing.
I’m not sure why you think ctypes isn’t portable, I have 8 lines of code in gfort2py that care about the OS (and that’s just for selecting the extension for shared libraries). It even works on Windows without me having even tried at that point to get it to work on Windows.
Works for personal projects where users are expected to “read the documentation” and compile accordingly for functionality… Not so useful as a basis for a generic tool.
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. Much like f2py wraps the messiness of building a python-c interface to present something useful to the user.
I don’t think the general attitude that
ctypesdoes the same thing is helpful in the least for general binding tools which can and are in use for production Python code.
Except it can. Sure ctypes on it’s own doesn’t help. But you wrap ctypes and then you can do anything you want. Gfort2py has support for scalars, explicit arrays, strings, assumed shape arrays, alloctable arrays, and derived types. Things not currently supported are more due to my time commitment instead of any fundamental limitations of using ctypes.