原作：Jake Edge

译者：豌豆花下猫@Python猫

英文：https://lwn.net/Articles/819853/

随着 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。