使用类型提示将 Python 转换为 Cython

类型提示现在在 Python 3.5 版本中可用。在规范 ( PEP 484 ) 中，目标（和非目标）被明确暴露：

#Rationale and Goals

此 PEP 旨在为类型注释提供标准语法，开放Python 代码更容易静态分析和重构、潜在的运行时类型检查以及（也许在某些情况下）利用类型信息生成代码。 [...]

在这些目标中，静态分析是最重要的。

#非目标

使用类型提示 性能优化 留给读者作为练习。

另一方面，Cython 长期以来一直使用静态语法来提高性能。通常，人们使用 Cython 语法重写一些代码，编译它们，然后将它们作为独立模块导入回来。在大型代码库上完成所有这些工作是一项痛苦的工作。但最糟糕的是，即使您正确遵循上述所有步骤，您也不能保证您会有真正的改进（因为如果您使用某些模块，可能会导致兼容性问题）。|| |编写一个工具来

使用这种新类型提示 分散在代码中的东西 自动将它们转换为 Cython 语法 并可能完成其余的工作（编译它们）将是一项艰巨的任务到模块并将它们全部导入回来）？因此，有可能在所有代码库中共享相同的语言语法。 理论上，可以编写这样的工具，但我不确定是否值得（就编写它的复杂性而言）真正的改进是产量）。

谢谢。

Thanks.

编写一个能够利用 Python 类型提示自动将 Python 代码转换为 Cython 代码的工具确实是一项艰巨的任务。这在技术上是可行的，但这并不简单，而且需要仔细权衡这种方法的复杂性和潜在收益。

让我们来探讨一下涉及的挑战和注意事项：

1. 类型提示的复杂性： Python 的类型提示系统虽然功能强大，但可能相当复杂。它支持泛型、Union 类型、可调用类型、文字类型等等。一个能够处理所有这些用例的强大工具需要一个全面的类型提示系统解析器和解释器。

2. Cython 的限制： Cython 虽然与 Python 紧密集成，但并不能支持 Python 类型系统的每个特性。某些高级类型提示（如使用 typing 模块中的 Protocol 或复杂泛型的提示）不能直接转换为 Cython 等效项。

3. 推断类型： 在许多情况下，类型提示可能并不详尽。一个好的工具将需要执行类型推断（类似于 MyPy 所做的）以填写缺失的类型信息。这本身就是一个复杂的任务。

4. 代码转换： 将类型提示转换为 Cython 的语法需要对 Python 和 Cython AST（抽象语法树）有深入的了解。该工具需要修改代码、添加 Cython 特定的声明并可能重构代码的某些部分以适应 Cython 的语义。

5. 编译和导入： 该工具需要处理 Cython 代码的编译过程，包括管理依赖项和确保正确导入生成的模块。这可能会给不同的系统和环境增加另一层复杂性。

潜在收益：

• 减少样板文件： 自动转换可以消除手动将代码转换为 Cython 语法的需要，从而减少样板文件并可能减少错误。
• 改进的维护： 在一个代码库中使用单个语法可以简化维护，并可能使不熟悉 Cython 的开发人员更容易做出贡献。
• 渐进式采用： 该工具可以促进对大型代码库进行渐进式 Cython 采用，从而允许开发人员专注于可以从性能改进中获益最大的关键部分。

值得吗？

最终，工具的价值取决于几个因素，例如项目的规模和复杂性、对性能的需求以及团队的专业知识。对于大型代码库，在关键性能部分中大量使用类型提示，这样的工具可以证明其开发成本是合理的。

替代方案：

• 逐步转换： 与其尝试完全自动化，不如考虑逐步将 Python 代码转换为 Cython，从性能关键部分开始。
• 混合方法： 将类型提示用于文档和类型检查（使用 MyPy 等工具），并使用显式 Cython 声明来获得性能至关重要的代码部分。

总之，虽然构建一个完全自动化的 Python 到 Cython 转换工具是一项艰巨的任务，但这并非不可能。仔细考虑权衡取舍、潜在收益以及项目的具体限制对于确定此方法是否值得至关重要。