原帖：JakeEdge译者：猫下的豌豆花@Python猫第一次，Python3.9的功能已经很完善了。在10月份的最终版本发布之前，还有很多测试和稳定性工作要做。（译注：beta1版本是5月18日发布，作者文章是5月20日写的，而这个译文发表的时候，beta2刚好在今天6月9日发布，纯属巧合！）发布说明列表七Python增强3.9的提案(PEP)被接受。我们查看了其中一些PEP并看到了一些更新。现在似乎是介绍Python3.9带来的一些东西的好时机。1.字符串操作有时是最简单（明显）也是最难的事情，或者至少引起了巨大的讨论。大多数争议是关于命名的（还有什么？），但是向标准字符串对象添加函数以删除前缀和后缀的想??法是没有争议的。这些词缀（统称为前缀和后缀）是否可以指定为一个序列，以便可以在单个调用中处理多个词缀，目前尚不清楚，最终从提案中删除，等待其他人再次推动更改。三月底，DennisSweeney在python-dev邮件列表上要求核心开发人员支持PEP616（“Amethodforremovingprefixesandsuffixesfromstrings”）。他指出了2019年3月关于该主题的python-ideas讨论。EricV.Smith同意支持PEP，这促使Sweeney发帖并开始讨论。在原始版本中，他使用cutprefix()和cutsuffix()作为添加到字符串对象的方法名称。四种类型的Python对象将获得新方法：str（Unicode字符串）、byte（二进制序列）、bytearray（可变二进制序列）和collections.UserString（字符串对象的包装器）。是这样写的：'abcdef'.cutprefix('abc')#returns'def''abcdef'.cutsuffix('ef')#returns'abcd'对于命名部分，出现了一堆建议。基本上很少有人喜欢“cut”，所以“strip”、“strim”和“remove”被提出来，都得到了一些支持。由于PEP中所述的原因之一，至少部分弃用了stripprefix()和stripsuffix()；现有的“strip”功能令人困惑，因此应避免重复使用该名称。str.lstrip()和str.rstrip()方法也用于删除前导字符和尾随字符，但对于真正寻求cutprefix()功能的程序员来说，它们是混淆的根源。*strip()在调用时接受一个字符串参数，但将其视为一组字符并从字符串的开头或结尾去除：'abcdef'.lstrip('abc')#返回“def”，如预期的那样'abcbadefed'.lstrip('abc')#返回'defed'，完全不是预期的最后，removeprefix()和removesuffix()似乎占了上风，这就是Sweeney最终改变的结果。GuidovanRossum也支持这些名称。EricFahlgren以这种方式滑稽地总结了命名辩论：我认为如果您先编写文档，名称的选择会更容易：cutprefix-删除指定的前缀。trimprefix-删除指定的前缀。stripprefix-去除指定的前缀。removeprefix-删除指定的前缀。废话:)Sweeney更新了PEP，回应了许多评论，还添加了建议字符串元组作为词缀的能力（请参阅PEPGitHub存储库中的版本）。但StevenD'Aprano不确定这是否有意义。他指出，唯一接受元组参数的字符串操作是str.startswith()和str.endswith()，它们不返回字符串（只是一个布尔值）。他对添加一个接受元组参数但返回字符串的方法持怀疑态度，因为无论选择什么规则来处理元组，对某些人来说都是“错误的”选择。例如：这里的难点在于，如果两个或多个前缀可以匹配，“删除其中一个前缀”的概念是不明确的。startwith没有区别："extraordinary".startswith(('ex','extra'))对于从左到右、最短-最大甚至随机顺序匹配都是True。但是对于cutprefix，应该去掉哪个前缀呢？正如他所说，建议的规则是使用从左到右处理元组的第一个匹配字符串，但有些人可能想要最长的匹配或最后的匹配；这完全取决于使用环境。他建议在承诺添加此类行为之前给该功能更多的“浸泡时间”：“在添加对多个前缀/后缀的支持之前，我们应该先在简单的案例上做一些实际工作。体验。”EthanFurman同意D'Aprano的观点。但是VictorStinner强烈支持元组参数的想法，除了他还想知道当传入的元组有一个空字符串时会发生什么。根据PEP提案，在处理元组时遇到空字符串（实际上可以匹配任何内容）只会返回原始字符串，这会导致令人惊讶的结果：cutsuffix("HelloWorld",("","World"))#returns"HelloWorld"cutsuffix("HelloWorld",("World",""))#returns"Hello"这个例子不太明显；词缀不一定是硬编码的，所以空字符串可能会滑到意想不到的位置。Stinner建议在遇到空字符串时抛出ValueError，类似于str.split()。但是Sweeney决定完全删除元组参数功能，以“允许对语义有更强烈看法的人在单独的PEP中提出和捍卫一组语义”。他在3月28日发布了最新版本的PEP。4月9日，Sweeney打开了一个指导委员会问题，要求审查他的PEP。4月20日，斯汀纳代表委员会接受了该提案。这是一个小改动，但值得花时间确保它具有长期适用的界面（和语义）。我们将在Python3.9中看到removeprefix()和removesuffix()。2.新的解析器毫不奇怪，指导委员会已经接受了我们在4月中旬推出的新的CPython解析器。PEP617（“CPython的新PEG解析器”）由Python创始人和前仁慈独裁者(BDFL)GuidovanRossum以及PabloGalindoSalgado和LysandrosNikolaou提出。它已经运行良好，并且在速度和内存使用方面比现有解析器提供了10%以内的性能提升。由于解析器基于解析表达式语法(PEG)，它还将简化语言规范。CPython现有的LL(1)解析器有许多缺点和一些hack，新的解析器将消除这些缺点。这一变化为Python超越LL(1)语法铺平了道路，尽管现有语言并不完全是LL(1)。此更改不会太快，因为计划是在Python3.9的命令行中提供开关，以保持现有解析器可用。但是Python3.10将移除现有的解析器，这可能会导致语言发生变化。如果进行了这些更改，其他Python实现（例如PyPy和MicroPython）将需要切换解析器的LL(1)实现以跟上语言规范。这可能会让核心开发人员暂停进行此类更改。3.更多内容我们在3月初查看了PEP615（“支持标准库中的IANA时区数据库”）。它将在标准库中添加一个zoneinfo模块，这将有助于从IANA时区数据库（也称为“Olson数据库”）中获取时区信息以填充时区对象。在撰写本文时，它似乎工作正常。3月底，PaulGanssle要求就PEP做出决议。他认为在一个有趣的时间范围内接受它可能会很有趣：......我希望（出于异想天开的原因）在4月5日星期日02:00-04:00或13:00UTC-17:30，因为这些时间代表地球上某些地方（主要是澳大利亚）的模糊时间。还有另一个时间，即4月19日星期日世界标准时间01:00-03:00之间，这在西撒哈拉是模棱两可的。他意识到这可能很难实现，而且肯定不是优先考虑的事情。指导委员会并没有错过第二次时间窗口；BarryWarsaw于4月20日宣布接受PEP。Python现在将拥有一种访问系统时区数据库以创建和操作时区的机制。或者，Python包索引(PyPI)中有一个tzdata模块，它为缺少它的系统提供IANA数据；它将由Python核心开发人员维护。PEP593（“灵活的函数和变量注释”）添加了一种将特定于上下文的元数据与函数和变量相关联的方法。事实上，类型提示注解已经挤掉了多年前在Python3.0中实现的PEP3107（“函数注解”）中设想的其他用例。PEP593使用注释类型提示为这些用例创建了一种新机制。PEP585（“标准集合中的类型提示泛型”）提供了另一种清理方法。它将允许删除在类型模块中维护的一组并行类型别名以支持泛型。例如，type.List类型将不再需要支持诸如“dict[str,list[int]]”之类的注释（例如，具有字符串键和整数列表值的字典）。字典“加法”的联合操作也将成为Python3.9的一部分。它有时会引起争议，但在2月中旬，PEP584（“将联合运算符添加到字典”）被VanRossum推荐采用。指导委员会很快同意，该功能于2月24日合并。最后一个PEP是PEP602（“Python的年度发布周期”）。正如提案中所写，它将发布节奏从每18个月更改为每年一次。但是，开发和发布周期重叠，因此整个功能开发需要12个月。当第一个Python3.9beta版本发布时（现在），Python3.10的功能开发就开始了。请继续关注来年的下一轮PEP。
