你找不到这个来源,因为这个来源是 bazel 自动生成的。如果您从源代码构建,您将在 bazel-genfiles 中看到此文件。它也存在于您的本地发行版中,您可以使用 inspect 模块找到它。该文件包含对底层 C++ 实现的自动生成的 Python 包装器,因此它基本上由一堆 1 行函数组成。找到这种生成的 Python 操作的底层 C++ 实现的捷径是将蛇案例转换为骆驼案例,即conv2d_backprop_input -> Conv2dBackpropInput
# figure out where gen_nn_ops is
print(tf.nn.conv2d_transpose.__globals__['gen_nn_ops'])
from tensorflow.python.ops import gen_nn_ops
import inspect
inspect.getsourcefile('gen_nn_ops.conv2d_backprop_input')
'/Users/yaroslav/anaconda/lib/python3.5/site-packages/tensorflow/python/ops/gen_nn_ops.py'
如果你想知道这个文件是如何产生的,你可以在BUILD 文件中跟踪 bazel 依赖项。它从 tensorflow 源树中找到生成它的 Bazel 目标:
fullname=$(bazel query tensorflow/python/ops/gen_nn_ops.py)
bazel query "attr('srcs', $fullname, ${fullname//:*/}:*)"
//tensorflow/python:nn_ops_gen
现在转到tensorflow/python 中的BUILD 文件,您会看到这是tf_gen_op_wrapper_private_py 类型的目标,它定义为here 并从tensorflow/tensorflow.bzl 调用gen_op_wrapper_py,看起来像这样
def tf_gen_op_wrapper_py(name, out=None, hidden=None, visibility=None, deps=[],
....
native.cc_binary(
name = tool_name,
native.cc_binary 构造是一种让 Bazel 目标表示执行任意命令的方法。在这种情况下,它使用一些参数调用tool_name。再走几步,你会发现这里的“工具”是从framework/python_op_gen_main.cc编译的
造成这种复杂情况的原因是 TensorFlow 被设计为与语言无关。因此,在理想世界中,您将在ops.pbtxt 中描述每个操作,然后每个操作将使用REGISTER_KERNEL_BUILDER 对每种硬件类型进行一个实现,因此所有实现都将在 C++/CUDA/Assembly 中完成并自动可用于所有语言前端。每种语言都会有一个等效的翻译器操作,例如“python_op_gen_main”,并且所有客户端库代码都将自动生成。然而,由于 Python 如此占主导地位,因此在 Python 方面存在添加功能的压力。所以现在有两种操作——在像gen_nn_ops.py 这样的文件中看到纯TensorFlow 操作,在像nn_ops.py 这样的文件中看到纯Python 操作,它们通常包装操作自动生成的文件gen_nn_ops.py,但添加了额外的功能/语法糖。此外,最初所有名称都是驼峰式,但决定面向公众的版本应该是 PEP 兼容更常见的 Python 语法,所以这是相同操作的 C++/Python 接口之间驼峰式/蛇式不匹配的原因