近日，Arch Linux 终于开始升级到 Python 3.9 了。很多人认为 Python 小版本升级容易搞坏兼容性，导致项目无法在新的版本上运行。事实是这样的吗？我正好借着 Arch Linux 升级 3.9 的机会，分析一下打包过程中失败的项目到底是出了什么事。
需要说明的是，我仅大致地分析了打包的报错信息，不排除分析出错，或者有额外的问题没有被看见的情况。另外我是在打包过程中随机（arbitrarily）取样，并且排除了我不能确定问题所在的案例。
以下项目测试失败是和 Python 3.9 相关的。排序是按照项目开发者的无辜程度排序的。也就是说，排序越靠前的，我越是认为项目开发者是无辜的；而像「硬编码 Python 3.9 为未发布的版本」这种完全不 future-proof 的做法，现在坏掉了真是自找的。
其中，使用的公开特性变化导致问题的有 3 个，调用私有属性或者方法、依赖非正式的文本信息的有 11 个，使用已废弃的特性的有 8 个，使用已被修复的 bug 的有 2 个，使用未来注定会出问题的信息的有 3 个。总共 27 个。
-
freecad:
PyTypeObject.tp_print没了 -
python-llfuse:
PyTypeObject.tp_print没了 -
linux-tools:
PyMODINIT_FUNC的变化导致了警告，然后被转为错误 -
python-blist:
_PyObject_GC_IS_TRACKED宏不再在第三方库中可用（被公开 API 取代） - python-pyflakes: Python 语法解析报告的列位置似乎不太对，应该是受新的语法解析器的影响
- python-pylint: Python 语法解析报告的列位置似乎不太对，应该是受新的语法解析器的影响
-
python-typing_inspect: 使用私有名称
typing._GenericAlias，结果新版本变成了typing._SpecialGenericAlias -
python-sphinx-autodoc-typehints: 看上去是类型标注相关的内部更改移除了
typing.Dict.__parameters__属性造成的 -
python-fastnumbers: 看上去是内部函数
_Py_dg_stdnan不再被默认包含导致的问题 -
python-libcst: 类型标注相关的内部更改移除了
typing.Dict.__args__属性造成的 -
monkeytype:
typing.Dict的类型从type变成了typing._SpecialGenericAlias -
scrapy: 由于
typing.Optional[str]的字符串表示由typing.Union[str, NoneType]变成了typing.Optional[str]导致 mitmproxy 运行出错，进而使得 scrapy 的测试失败 -
python-billiard: 调用的私有方法
_posixsubprocess.fork_exec参数发生了变化 - python-pytest-benchmark: argparse 的帮助信息格式有优化
-
python-opentracing: 自 3.7 起废弃的
asyncio.Task.current_task被移除 -
python-engineio: 自 3.7 起废弃的
asyncio.Task.all_tasks被移除 -
impacket: 自 3.2 起废弃的
array.array.tostring()被移除 -
python-pybtex: 自 3.2 起废弃的
xml.etree.ElementTree.Element.getchildren被移除 -
python-jsonpickle: 自 3.1 起废弃的
base64.decodestring被移除 -
python-ioflo: 自 3.1 起废弃的
json.loads()参数encoding被移除 -
routersploit: 自 Python 3 起废弃的
threading.Thread.isAlive终于被移除了 -
python-socketpool: 自 Python 3 起废弃的
threading.Thread.isAlive终于被移除了 - python-furl: Python 3.9 修正了一处 URL 解析 bug
-
python-stem: Python 3.9 移除了错误的
unittest.mock.__version__ - python-natsort: Python 的 Unicode 支持更新到了 13.0.0 版本，CHORASMIAN NUMBER ONE 字符被判定为数字，但是测试代码不认识，认为程序出错
- python-pony: 对新版本的 Python 报不支持的错误
- python-dephell-pythons: 硬编码 Python 3.9 为未发布的版本，但现在 3.9 已经发布了
而以下项目的测试失败与 Python 3.9 没有直接关系，共 26 个。其中与 Python 生态有关的有 18 个，与其它项目有关的有 4 个，依赖外部信息的有 3 个，包括一个特别搞笑的依赖夏令时是否生效的。
- python-eventlet: 调用的 dnspython 私有方法已不存在；DNS 解析超时
- python-markdown2: 语法高亮的结果有少许变化，不符合预期。推测是 pygments 新版本的变化
- python-flake8-typing-imports: 似乎是 flake8 能够检测到更多的问题了
- python-babel: 使用了已废弃的特性，测试被 pytest 拒绝
- python-pygal: pytest 6.1.0 移除了 Metafunc 的 funcargnames 属性
- python-flask-gravatar: 使用了已废弃的特性，测试被 pytest 拒绝
- python-pytest-relaxed: 使用了已废弃的特性，测试被 pytest 拒绝
- python-pytest-randomly 使用了已废弃的特性，测试被 pytest 拒绝
- python-deprecated: 测试所预期的警告文本信息已经发生变化
- python-dbus-signature-pyparsing: 执行时间超过了测试设定的 200ms 时限
- python-tinycss2: flake8 风格检查未通过
- python-pytest-runner: black 风格检查未通过
- python-portend: black 风格检查未通过
- python-aiohttp: @coroutine 的 DeprecationWarning 被视作错误
-
python-poetry: poetry-core 的一项数据由
dict改为OrderedDict，使得输出顺序与测试预期的不一致 - python-isort: 将使用旧版本 isort 的外部项目的 import 排序视为正确，然后它还真出错了
- python-cachecontrol: Python 2.7 相关
- python-zc.lockfile: 测试代码把 Python 3 代码喂给了 Python 2.7。可能是该库已经不支持 2.7 了
- python-occ-core: 依赖 OpenCASCADE 的版本更新，不被支持
- protobuf: C 整型比较因表示范围问题而恒为假，警告转错误。是因为新版本的 gcc 比较聪明么？
- gnome-passwordsafe: 构建系统发现有依赖缺失
- io: C 代码引用了不存在的系统头文件
- ceph: C++ 相关问题
- python-distlib: 调用远程 XML-RPC 太多被限制导致预期的数据与实际错位
- python-requests-toolbelt: 测试所需要的 HTTP 资源 404 了
- postgresql: 夏令时结束，导致实际时区与预期对不上。「所以冬天就不要滚包啦，冬天要冬眠！」
所以在这些升级 Python 3.9 的项目中，不兼容 Python 3.9 仅仅只占一半，其中又有一半多属于「总有一天会坏掉」的类型（一大半属于「不听话」，使用没有明确文档、预期为私有的特性，少数尝试当预言家但是失败了）。最后剩下的，再一大半是使用了至少两个版本前已经说了要废弃的特性，只有三个莫名地发现自己真的被 Python 坑了，还都是 C API 部分的。
所以我对我自己的脚本顺利升级到 Python 3.9 非常有信心呢。可能有些老代码使用了已经废弃的特性，所以我也设置了环境变量 PYTHONWARNINGS=default,ignore::ResourceWarning 以便及时得到提示。
哦对了，Arch Linux 中受 Python 3.9 升级影响需要更新的软件包共有2077个，绝大部分我都没见着失败的。目前从开始升级到现在已经过去六天，还剩最后40个失败了的包。
