原作:Jake Edge
译者:豌豆花下猫@Python猫
随着 Python 3.9.0b1 的发布,即开发周期中计划的四个 beta 版本的首个,Python 3.9 的功能已经是完善了。在 10 月发布最终版本之前,还会有许多测试和稳定性方面的工作要做。
(译注:beta1 版本发布于 5 月 18 日,作者文章写于 5 月 20,而到本篇译文发布时,beta2 刚好在今天即 6 月 9 日发布,这是一个巧合!)
该发布说明中列出了被 3.9 接受的 7 个 Python 增强提案(PEP)。我们研究了其中的一些 PEP,看到有一些更新。现在似乎是一个介绍 Python 3.9 带来的一些东西的好时机。

1、字符串操作

有时最简单(表明上的)的事情最困难,或者至少会引起巨大的讨论。其中大部分的争议是关于命名(还能是什么?),但是给标准字符串对象添加函数,来删除前缀和后缀,这种想法是毫无争议的。
是否可以将那些词缀(前缀和后缀的统称)指定为序列,以便在一次调用中处理多个词缀,这一点尚不明确,最后它被从提案中删除了,等待着其他人再次推动更改。
在 3 月底,Dennis Sweeney 在 python-dev 邮件列表上请求核心开发者支持 PEP 616(“字符串删除前缀和后缀的方法”)。他指出了自 2019 年 3 月以来关于该话题的 python-ideas 讨论。埃里克·史密斯(Eric V. Smith)同意支持该 PEP,这促使 Sweeney 发布并启动了讨论。
在最初版本中,他使用 cutprefix() 和 cutsuffix() 作为要添加给字符串对象的方法名。四种类型的 Python 对象将获得新的方法:str(Unicode 字符串),byte(二进制序列),bytearray(可变的二进制序列)和 collections.UserString(字符串对象的一种封装)。
它的写法如下:
'abcdef'.cutprefix('abc') # 返回'def'
'abcdef'.cutsuffix('ef') # 返回'abcd'
针对命名部分,出现了一大堆的建议。基本上很少有人喜欢“cut”,因此“strip”、“strim”和“remove”被提出来了,并且都获得了一些支持。
stripprefix() 以及 stripsuffix() 由于 PEP 中指出的一种理由,至少是被部分地反对了;现有的“strip”函数令人困惑,因此应避免重用该名称。
str.lstrip() 和 str.rstrip() 方法也用于删除前导字符和尾随字符,但是它们对于真正在寻找 cutprefix() 功能的程序员来说是一个困惑的来源。
*strip() 在调用时接收一个字符串参数,但会将其视为一组字符,并从字符串开头或结尾消除:
'abcdef'.lstrip('abc') # 返回“def”,符合预期
'abcbadefed'.lstrip('abc') # 返回'defed',完全不符合预期
最终,removeprefix() 和 removesuffix() 似乎占据了上风,这正是 Sweeney 最终改成的版本。Guido van Rossum 也支持这些名字。
埃里克·法格伦(Eric Fahlgren)这样搞笑地总结了命名的争论:

我认为如果你先写文档,则名称的选择会更容易些:

cutprefix - 删除指定的前缀。

trimprefix - 删除指定的前缀。

stripprefix - 删除指定的前缀。

removeprefix - 删除指定的前缀。废话 :)

Sweeney 更新了 PEP,回应了许多评论,但还增加了提议将字符串元组作为词缀的功能(可以在 PEP GitHub 仓库中看到该版本)。
但是史蒂文·达普拉诺(Steven D’Aprano)不确定这样做是否合理。他指出,唯一接受元组参数的字符串操作是 str.startswith() 和 str.endswith(),而它们不返回字符串(只是一个布尔值)。他怀疑添加这一种接收元组参数却返回字符串的方法,因为无论选择何种规则来处理元组,对于某些人来说都是“错误的”选择。
例如:

这里的困难在于,如果两个或多个前缀都能匹配,则“剪切这些前缀中的一个”的概念是模棱两可的。对 startwith 没有区别:

 "extraordinary".startswith(('ex', 'extra'))

因为是从左到右,从最短到最大,甚至是随机顺序匹配都为True。但是对于 cutprefix,应该删除哪个前缀?

如他所说,建议的规则是使用从左到右处理元组的第一个匹配字符串,但是有些人可能想要最长的匹配或最后一个匹配;这一切都取决于使用的上下文。他建议在提交添加此类行为之前,要给该功能更多的“浸泡时间”(译注:即预备时间):“在添加多前缀/后缀的支持之前,我们首先应该对简单的情况进行一些实际的体验。”
伊桑·弗曼(Ethan Furman)同意达普拉诺(D’Aprano)的意见。但是维克托·斯汀纳(Victor Stinner)强烈赞成元组参数的想法,只不过,他还想知道当传入的元组有空字符串时,会怎么处理。根据 PEP 提议,在处理元组时遇到空字符串(实际上可以匹配任何内容)只会返回原始字符串,这会导致令人惊讶的结果:
cutsuffix("Hello World", ("", " World"))    # 返回 "Hello World"
cutsuffix("Hello World", (" World", ""))    # 返回 "Hello"
这个例子不太明显;词缀不一定是硬编码的,因此空字符串可能会溜进意想不到的位置。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。