No migration from Go to Python

我理解我们不需要把 Go code 迁移到 Python。

SQLFlow 语法里有以下部分和 Python 有联系： TO TRAIN 后面接的 mode definition，很可能是 Python 实现的，因为更底层的 API 如 TensorFlow、PyTorch 都是 Python 写的。不过这个不绝对，比如 Katib 是 Go 写的，接口是 YAML；optflow 也不是 Python 的。 WITH {key=value} 里的 value 可能是 Python expression 的一个子集。但是要看到 key=value 这个形式本身并不是 Python 语法。 COLUMN bucketize(vocabularize(address)) 这里的 column transform functions 如 vocabularize 和 bucketize 对应到 codegen 结果中的一些 Python 函数，例如 TensorFlow codegen 会把他们对应到 TensorFlow Feature Column API 函数。但是并不绝对，也可能会被其他 codegen 对应到其他形式的底层函数。

可以看到，上述没有一项是完全 Python 语法的，反而每一项都是努力贴近 SQL 语法，远离 Python 语法的。并且，代码生成的过程中，上述部分都不会简单地被 copy-and-paste 到编译结果里。所以，我理解我们不需要把 middle end 和 back end 移植到 Python 语言。

我仔细看了玉哥的总结，其中提到了上述 1. 和 3.，没有提到 2.。这个总结里说到很多概念在 Go 和 Python code 里有重叠的对应。我理解这些“重复”是必要的，因为本来就在两个不同概念层次上。Go 里的 type BucketColumn 对应的是 SQL 语法里的 bucketize。Go 里的 type VocabularizeColumn（现在没有，但是应该有）对应 SQL 语法里的 vocabularize。Go 里的 HashColumn 对应 SQL 语法里的 hash —— 这些都是一一对应的，因为 Go 里的内容是 IR 的一部分，而 IR 需要和语法定义一致。

在 TensorFlow codegen 产生的 Python code 里，bucketize(vocabularize(...)) 对应到 tf.feature_column.categorical_column_with_vocabulary_list(..., num_oov_buckets=0 ) —— 请注意，这里两个 SQLFlow column transformation functions 的嵌套调用被映射成一个 Python 函数调用，所以并非一一对应的。

这个不一一对应，也说明了 “Go代码里的内容“ 和 Python 代码里的不是“重复的”。