Python3.9 beta2版本发布了,看看这7个新的PEP都是什么

Python3.9 beta2版本发布了,看看这7个新的PEP都是什么

原作：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。

到此这篇关于Python3.9 beta2版本发布了,看看这7个新的PEP都是什么的文章就介绍到这了,更多相关Python3.9 beta2版本新PEP内容请搜索考高分网以前的文章或继续浏览下面的相关文章希望大家以后多多支持考高分网！