如果 Python 外部库支持 Python3 独有特性，那么它如何在向后兼容 Python2 时不会导致解释器问题？

如何解决如果 Python 外部库支持 Python3 独有特性，那么它如何在向后兼容 Python2 时不会导致解释器问题？

关于外部库的一些问题，以及旧版 Python 解释器如何处理利用旧版解释器不具备的功能的外部库，以及打包可能向后兼容的库。

我第一次使用 matmul 运算符和 numpy 时遇到了这个问题 - matmul (@) 运算符是 3.5 的一个特性，当我创建这个简单的例子时

import numpy as np 

array1 = np.array([[1,2],[3,4]])
array2 = np.array([3,4])
array3 = array1 @ array2

如果我通过 python2.7.16 运行它，它会抛出一个无效的语法错误，并且在 python3.7 中没问题。如果在某个地方必须具有早期 Python 中不存在的 __matmul__ dunder，为什么跟踪不在 numpy 本身中？同样是类型提示的问题：当我用类型提示更新那一小块代码时，它会导致 2.7 到处出现语法错误 - 如果有人为 3.x 制作了很好的包，里面有有用的类型提示，3.5 功能，有人 pip 安装它来自一个鸡蛋或轮子，然后通过 python2 运行它，解释器如何处理它？ f 弦也一样，增加了 3.5/3.6。我这么问是因为我有一个包我想作为轮子分发，理想情况下它适用于 2.7，但我到处都有类型提示和 f 字符串。

我想我的问题的总结是：如果可以，您如何保证您的包及其所有优秀的 python3 功能向后兼容旧的 Python？使用外部库或从轮子/鸡蛋安装的东西与导入有何不同？ （特别是对于一个鸡蛋，据我所知它仍然提供原始源代码，而轮子有某种编译/“构建”正在进行（不确定在 Python 上下文中“构建”是什么意思，我的理解是你提供解释器的源代码，它在运行时生成字节码，解释器永远不会像编译语言一样“构建”（编译）目标文件或可执行文件））

解决方法

总的来说，要么是侥幸，要么他们实际上避免使用任何 Python 3 功能，即使他们提供了对此类功能的支持。

如果在某个地方必须有早期 Python 中不存在的 __matmul__ dunder，为什么跟踪不在 numpy 本身中？

仅将方法命名为 __matmul__ 在 Python 2 上不是语法错误。尝试使用 @ 运算符是语法错误。 （不过，NumPy 不再支持 Python 2，所以要么您使用的是旧版 NumPy，要么导入时没有错误完全是侥幸。）

同样是类型提示的问题：当我用类型提示更新那一小块代码时，它会导致 2.7 到处出现语法错误——如果有人为 3.x 制作了很好的包，里面有有用的类型提示，这是 3.5 的一个特性，有人 pip 从鸡蛋或轮子安装它，然后通过 python2 运行它，解释器如何处理？

有一种适用于 Python 2 的“类型注释”语法，或者它们可以分发单独的类型存根文件而不是使用内联注释。如果他们直接在 .py 文件中使用注释语法，那将导致语法错误。

同样的 f-strings，增加了 3.5/3.6。

语法错误。

我之所以这么问是因为我有一个包我想作为轮子分发，理想情况下它适用于 2.7，但我到处都有类型提示和 f 字符串。

您有不切实际的兼容性期望。您必须使用类型注释和 str.format。

如果可以，您如何保证您的软件包及其所有出色的 Python3 功能向后兼容旧版 Python？

不使用 Python 3 功能。