Python 3.8抢先看

Python 3.8定于今年11月(2019年)发布。第一个测试版——在此之后没有新特性——在一段时间之前就已经发布了。我决定看看它带来了哪些新东西，并尝试一些看起来很有趣的新功能。

赋值表达式

又称“海象运算符”(:=)。Python历史书中有一章专门介绍PEP 572(赋值表达式)：Python之父Guido van Rossum在围绕PEP 572进行了激烈的讨论之后，从BDFL宝座上退了下来(或“永久休假”)。有人可能会说，PEP 572是该语言历史上最具争议的PEP之一。这一事件导致了治理模型的出现，在该模型中，与PEP相关的决策的权力归属于一个由5人组成的指导委员会。

我们来看看赋值表达式到底是怎么回事。其基本思想是一个可以被命名的表达式。下面是一些例子:

这实际上让我们以更简洁的方式来编写代码。假设你有这段3.8版本之前的代码:

升级到3.8之后，你可以将其重构为:

我们把这段代码的嵌套特性+其他丑陋点放在一边，只关注代码行数:它是9(前3.8版本前)对6(3.8+版本)行。这样的模式并不罕见。PEP文档中提到的一个例子是对正则表达式进行匹配：尝试其中一个，如果不匹配，则继续下一个。

总的来说，我对此有一点混乱的感觉。当然，语法在开始的时候有点混乱，但是我想经过一些修改之后就会觉得很自然了。我个人更关心的是新来者：每一个新的语法糖块都会使Python进一步远离“你可以像读英语一样阅读的语言”。当然，一些简单的(令人困惑的)技巧在新手学习之初就对他们是隐藏的，但是我仍然觉得赋值表达式可能会降低语言的整体可读性。另一方面，在3.8发布之后，有的人可能会将他的10行脚本重构为8行脚本(准确的平均值)，这绝对是该特性有利的一面。Python将变得更加紧凑。

Positional-only 参数

这个特性的基本思想是，开发者可以在函数定义中使用 / 来指明前面的参数是positional-only。如果调用者在需要positional-only参数时使用了关键字参数，则调用者将收到一个TypeError提示。

这里是一个最简短的例子：

我想说的是，keyword-only参数是对已经存在的东西的一种扩展，只是没有被广泛熟知或使用。令人惊讶的是，positional-only参数没有与keyword-only参数同时引入。然而，现在positional-only参数也将被支持，函数/方法签名已经开始是“功能完整的”。这些*-only参数的优点之一是为库作者提供了一种温和的方式来强制执行他们所提供的API的预期调用行为。如果使用得当，*-only参数将在API实现和调用程序代码中提高该API的可读性。positional-only参数的一个优点是，库作者可以自由地更改参数名，而不会破坏向后兼容性。

下面是一个函数定义的例子，它包含了所有的参数类型:

其中：

a: positional-only参数

b: 位置或关键字

c: keyword-only参数

因此，func 就可以像这样被调用：

但不是像这样：

我认为positional-only参数将是最有价值的，并且会在处理某种数学运算的库中使用。如果某个人在函数定义中使用了诸如a、b或类似的参数名，那么这可能是一个使用positional-only参数的潜在标志。

运行时审计钩子

这个目标显然是出于安全目的。另一方面，我也相信它将带来一组核心开发团队没有必然预见到的用例。当人们得到新玩具玩的时候，他们往往很有创造力。

这里是一个简单的例子：

我们来运行它：

在编写本文时，由CPython运行时触发的内置事件还没有文档化，但是文档占位符在这里已经存在。PEP 578提到了使用审计钩子的明显缺点：一旦开发人员添加了审计钩子，他们就已经明确地选择用性能换取功能。

我们也可以使用自定义事件:

预期的用例显然倾向于安全性。一旦3.8版本发布，我将会看到许多新的安全相关的工具/库，它们将大量地使用新的内置审计钩子特性。也许一些现有的库还添加了一个可选特性，用于审计由库本身触发的事件。

总结

我的观点: positional-only参数和运行时审计钩子可能是普通Python用户不会使用(也不会看到它们被使用)的东西，而赋值表达式特性将会产生更显著的影响。我觉得Python社区的数据科学部分至少对赋值表达式很满意，因为在R语言中也有类似的功能。

英文原文：https://blog.jerrycodes.com/sneak-peek-python-3-8/

译者：野生大熊猫