当我在NumPy的源代码树中列出所有Fortran文件时,我得到:
./doc/source/f2py/scalar.f
./doc/source/f2py/string.f
./doc/source/f2py/calculate.f
./doc/source/f2py/moddata.f90
./doc/source/f2py/array.f
./doc/source/f2py/allocarr.f90
./doc/source/f2py/extcallback.f
./doc/source/f2py/common.f
./doc/source/f2py/ftype.f
./doc/source/f2py/fib3.f
./doc/source/f2py/callback.f
./doc/source/f2py/fib1.f
./doc/f2py/f2python9-final/src/examples/exp1.f
./doc/f2py/simple.f
./doc/f2py/multiarray/foo.f
./doc/f2py/hello.f
./doc/f2py/ex1/bar.f
./doc/f2py/ex1/foobar-smart.f90
./doc/f2py/ex1/foo.f
./doc/f2py/ex1/arr.f
./doc/f2py/ex1/foobar.f90
./numpy/f2py/tests/src/mixed/foo_fixed.f90
./numpy/f2py/tests/src/mixed/foo_free.f90
./numpy/f2py/tests/src/mixed/foo.f
./numpy/f2py/tests/src/size/foo.f90
./numpy/f2py/tests/src/kind/foo.f90
./numpy/f2py/tests/src/assumed_shape/precision.f90
./numpy/f2py/tests/src/assumed_shape/foo_use.f90
./numpy/f2py/tests/src/assumed_shape/.f2py_f2cmap
./numpy/f2py/tests/src/assumed_shape/foo_free.f90
./numpy/f2py/tests/src/assumed_shape/foo_mod.f90
./numpy/f2py/src/test/bar.f
./numpy/f2py/src/test/foo.f
./numpy/f2py/src/test/foo90.f90
./numpy/f2py/src/test/wrap.f
./numpy/distutils/tests/f2py_ext/src/fib1.f
./numpy/distutils/tests/f2py_f90_ext/include/body.f90
./numpy/distutils/tests/f2py_f90_ext/src/foo_free.f90
所以除了f2py之外,其他人都使用Fortran.我研究了线性代数模块.对于LAPACK,有一个make_lite.py从一个LAPACK源树中仅提取必要的子程序文件,以及使用它们转换成C f2c.因此,在创建NumPy的过程中,创建它是否方便f2py？我错过了什么吗？
编辑
事实证明,SciPy中的很多软件包都使用f2py.运行
$ find . -iname '*.f*' | cut -d'/' -f3,4 | uniq
给我填写Fortran文件的确切目录:
linalg/src
fftpack/src
odr/odrpack
special/cdflib
special/amos
special/mach
special/specfun
integrate/quadpack
integrate/odepack
integrate/dop
integrate/linpack_lite
integrate/mach
sparse/linalg
interpolate/fitpack
optimize/minpack2
optimize/minpack
optimize/nnls
optimize/cobyla
optimize/lbfgsb
optimize/slsqp
stats/mvndst.f
stats/futil.f
stats/statlib
_build_utils/src
lib/lapack
好吧，经过一番探索后，我想我已经证实了我最初的一些怀疑
第一的：
因此，除了
f2py它自己之外，没有人使用 Fortran。
正如我在评论中提到的，OP 引用的所有 Fortran 源文件都在/test/或/doc/目录中，因此我怀疑它们用于测试和记录f2py（以及numpy.distutils，它使用f2py）。浏览一些源文件似乎证实了这一印象。f2py本身看起来像是用 Python 和 C 编写的。
我研究了线性代数模块。对于 LAPACK，有一个 make_lite.py 文件，它从 LAPACK 源树中仅提取必要的子例程，并使用以下命令将它们转换为 C 语言：
f2c
这对我来说似乎很奇怪，因为我实际上没有f2c安装（或者Plex，这是似乎需要的另一个库make_lite.py）。我决定添加一行额外的内容来main()显示make_lite.py在正常安装过程中是否实际使用：
...
def main():
# let's see if you're actually doing anything
import subprocess; subprocess.call(['touch', '/tmp/hello_from_make_lite'])
...
hello_from_make_lite果然，在干净的 virtualenv 中安装 numpy 后， my 中没有文件/tmp/，表明make_lite.main()从未执行过。看一眼numpy/linalg/lapack_lite/README：
、和 是
numpy/linalg/blas_lite.c模块所需的 LAPACK 例程的版本，并由模块包装 。此目录中的脚本可用于从 LAPACK 源文件目录自动创建这些文件。numpy/linalg/dlapack_lite.cnumpy/linalg/zlapack_lite.cf2cLinearAlgebralapack_lite
因此 numpy 已经随这些 'd C 源文件一起分发了-除非您是一个开发人员想要从新版本的 LAPACK 库更新这些函数，否则f2c不需要使用。make_lite.py
那么，在创建 NumPy 的过程中，什么时候方便创建呢
f2py？
据我所知，在正常的 numpy 安装过程中根本f2py不会被使用。我再次在其中添加了一行：f2py2e.main()
...
def main():
import subprocess; subprocess.call(['touch', '/tmp/hello_from_f2py2e'])
...
再说一次，/tmp/hello_from_f2py2e正常安装 numpy 后就不存在了。
那么f2py实际用途是什么呢？查看 scipy 源代码树，并从其根调用
$ find . -iname *.f*
您将看到大量看起来很重要的 Fortran 文件，包括fftpack、odepack、arpack、fitpack等。我怀疑这f2py主要是包装 scipy 而不是 numpy 的 Fortran 扩展所必需的。
不过，我可能是错的——也许 numpy 或 scipy 开发人员之一会纠正我的观点。
实际上，我认为f2py在 scipy 的正常安装过程中实际上也不需要！如果您查看其中一个 Fortran 模块的源目录，例如fftpack，您将看到它已经包含.pyf文件，这些文件通常由f2pyFortran 函数自动生成并定义 Fortran 函数的接口（请参见此处）。
我认为问题是它f2py最初用于生成.pyfFortran 函数的包装器，但这些文件与源树的其余部分一起分发，因此在正常构建过程中.pyf无需再次运行。f2py