近日,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个失败了的包。