这个例子不太明显;词缀不一定是硬编码的,因此空字符串可能会溜进意想不到的位置。Stinner 建议如果遇到空字符串,则抛出 ValueError,类似于 str.split()。但是 Sweeney 决定完全删除元组参数功能,以便“允许对此有更强见解的人在另外的 PEP 中提出并捍卫一系列的语义”。他在 3 月 28 日发布了该 PEP 的最新版本。
4 月 9 日,Sweeney 发起了一个指导委员会 issue,请求对其 PEP 进行评审。4 月 20 日,Stinner 代表委员会接受了该提案。
这是一个很小的更改,但值得花时间确保它具有长期适用的接口(和语义)。我们将在 Python 3.9 中看到 removeprefix() 和removesuffix()。
2、新解析器
并不令人感到惊讶的是,指导委员会已经接受了我们在 4 月中旬介绍过的 CPython 新解析器。PEP 617(“CPython 新的 PEG 解析器”)由 Python 创始人即前仁慈的独裁者(BDFL) Guido van Rossum 以及 Pablo Galindo Salgado 和 Lysandros Nikolaou 共同提出。
它已经运行良好,并且在现有解析器的速度和内存使用方面提升了 10% 以内的性能。由于解析器是基于解析表达语法(PEG),因此也将简化语言规范。CPython 现有的 LL(1) 解析器存在诸多缺点和一些 hack,新的解析器将会消除掉。
这一更改为 Python 超越 LL(1) 语法铺平了道路,尽管现有语言并不完全是 LL(1)。这一更改不会太快,因为计划是在 Python 3.9 的命令行中提供开关,保持现有解析器可用。
但是 Python 3.10 将删除现有的解析器,这可能会导致语言变更。如果做了那些更改,那么,其它的 Python 实现(例如 PyPy 和 MicroPython)就需要切换解析器的 LL(1) 实现,以便跟上语言规范的要求。这可能会使核心开发者暂停进行此类更改。
3、更多内容
我们在三月初查看了 PEP 615(“在标准库中支持 IANA 时区数据库”)。它将在标准库中添加一个zoneinfo
模块,该模块将有助于从 IANA 时区数据库中(也称为“Olson数据库”)获取时区信息,以填充时区对象。在撰写本文时,它看起来很顺利。
在 3 月底,Paul Ganssle 请求就该 PEP 作出决议。他认为在一个有趣的时间范围内接受它,可能会很有趣:
… 我希望(出于异想天开的原因)在 4 月 5 日(星期日)UTC 时间 02:00-04:00 或 13:00-17:30 之间接受它,因为这些时间代表着地球上某些地方的不明确时间(主要在澳大利亚)。还有另一个时机,那就是在 4 月 19 日星期日 UTC 01:00-03:00 之间,这段时间在西撒哈拉是不明确的。
他意识到这可能难以实现,它当然不是优先考虑的事。指导委员会没有错过第二个时间窗太多;Barry Warsaw 于 4 月 20 日宣布接受该 PEP。
Python 现在将具有一种机制来访问系统的时区数据库,以创建和处理时区。另外,Python 软件包索引(PyPI)中有一个 tzdata 模块,它为缺少 IANA 数据的系统提供这些数据;它将由 Python 核心开发者维护。
PEP 593(“灵活的函数和变量注释”)添加了一种将上下文特定的(context-specific)元数据与函数和变量关联的方法。实际上,type hint 注解已挤出了很多年前在 Python 3.0 中实现的 PEP 3107(“函数注释”)中设想的其它用例。PEP 593 使用注解的(Annotated)类型提示为这些用例创建了一种新的机制。
PEP 585(“标准集合中的类型提示泛型”)提供了另一种清除方法。它将允许删除在 typing 模块中维护的一组并行的类型别名,以支持泛型。例如,type.List 类型将不再需要支持诸如“dict[str,list[int]]”之类的注解(例如,一个带有字符串键和整数列表的值的字典)。
字典“加法”的联合操作也会是 Python 3.9 的一部分。它曾不时引起争议,但是 2 月中旬,PEP 584(“给字典添加联合操作符”)被 Van Rossum 推荐采纳。指导委员会迅速同意了,该特性于 2 月 24 日合入。
最后一个 PEP 是 PEP 602(“Python 的年度发布周期”)。如提案所书,它将发布节奏从每 18 个月更改为每年一次。但是,开发和发布周期是重叠的,因此整个功能开发需要 12 个月的时间。当第一个 Python 3.9 beta 版本发布时(即现在),Python 3.10 的功能开发就开始了。请继续关注来年的下一轮 PEP。