Python 3.9 新特性:任意表达式可作为装饰器!

栏目: IT技术 · 发布时间: 4年前

内容简介:一个月前(2月20日),一则新的 PEP 没有受到任何阻碍就被官方采纳了,这么快的速度,似乎并不多见。然而,更为高效率的是,仅在半个月内,它的实现就被合入了代码仓。也就是说,我们最快有望在 3 天后(3月23日)发布的 3.9.0 alpha 5 版本中看到它!Python 3.9 的发布计划:

一个月前(2月20日),一则新的 PEP 没有受到任何阻碍就被官方采纳了,这么快的速度,似乎并不多见。

然而,更为高效率的是,仅在半个月内,它的实现就被合入了代码仓。也就是说,我们最快有望在 3 天后(3月23日)发布的 3.9.0 alpha 5 版本中看到它!

Python 3.9 的发布计划:

Python 3.9 新特性:任意表达式可作为装饰器!

这个 PEP 就是 PEP-614:放宽对装饰器的语法限制。

当前装饰器的语法为:

decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE

PEP-614 提议将其简化为:

decorator: '@' namedexpr_test NEWLINE

我已经把 PEP 全文翻译出来了,Github 地址: http://dwz.date/RV9

放宽对装饰器的限制,这对之前的用法没有影响,但至于会带来哪些新的好处,我还不知道有哪些现实的例子。

下面是 PEP 翻译后的核心内容摘录,先跟大家一睹为快吧:

--------------摘录分割线----------------

概要

Python 当前要求所有装饰器都由 dotted name 组成,可选地带一个调用。本 PEP 提议消除这些限制,并允许任何有效的表达式作为装饰器。

(译注:dotted name,指的是装饰器在“@”符号后是“xxx”或“xxx.yyy”这种格式。没有很好地译法,故未译。)

动机

在最初引入装饰器时, Guido表示 对其语法作限制是一种偏好,而不是因为技术的要求:

我对此有一种直觉。我不确定它来自哪里,但我就是有……因此,尽管将来将语法更改为 @test 相当容易,但我仍想坚持使用更受限的形式,除非给出了真正的使用 @test 会增加可读性的用例。

尽管在实践中很少遇到问题,但是多年来, BPO问题邮件列表帖子 不断出现,要求去除限制。 最近的一封邮件 (它 促成了本提案 )提供了一段很好的使用 PyQt5 库的示例代码,如果放宽现有的限制,它将变得更具可读性、地道性和可维护性。

稍作修改的示例:

buttons = [QPushButton(f'Button {i}') for i in range(10)]

# Do stuff with the list of buttons...

@buttons[0].clicked.connect
def spam():
    ...

@buttons[1].clicked.connect
def eggs():
    ...

# Do stuff with the list of buttons...

当前,这些装饰必须重写成这样(译注:上方是假想的最优写法,但 Python 还不支持,只能用下方的啰嗦写法):

button_0 = buttons[0]

@button_0.clicked.connect
def spam():
    ...

button_1 = buttons[1]

@button_1.clicked.connect
def eggs():
    ...

此外,当前的语法太过宽松,以至于无法将更复杂的装饰器表达式结合在一起。也就是说,当前的限制并没有像预期的那样去禁止任意复杂的表达式,而是使它们变得更丑陋且效率低下:

# Identity function hack:

def _(x):
    return x

@_(buttons[0].clicked.connect)
def spam():
    ...

# eval hack:

@eval("buttons[1].clicked.connect")
def eggs():
    ...

原理

允许任意表达式

在相当长的一段时间内,允许任意有效表达式的决定(而不仅仅是放宽当前的限制,如允许取下标),已被视为装饰器语法发展的下一个顺理成章的步骤。正如 Guido 在另一个邮件列表讨论中所说

我觉得强制约束它没有什么道理,因为它已不再是一个普通的表达式。

若对语法进行特殊设置以允许某些有用的用法,只会使当前情况复杂化,并且几乎能肯定此过程会在将来的某个时间重复。此外,这种语法上的改变的目的之一是阻止使用上述的 eval 和反模式的 identity-function 之类的诱惑。

简而言之:如果要删除一些限制,我们应该删除所有限制。

什么算一个“表达式”

在本文档中,“表达式”一词的用法与《 Python语言参考 》中定义的相同。可以概括为“任何在 if、elif 和 while 块中测试为有效的内容”。

这与可能更流行的 定义 稍有不同,后者可以概括为“任何作为有效字符串输入给 eval 的内容”。

前一个“表达式”的定义更方便,因为它非常贴合我们的需求,并且可以重用被现有语言结构所允许的语法。与其它定义相比,它有两个细微的差异:

1、元组必须加括号

这是基于 Guido 在同一封邮件中的洞察。紧接着前面的引述:

但是我不会允许逗号,决不可能赞成这样:

@f, g
def pooh(): ...

确实,它可能甚至导致没有经验的读者得出结论,认为正在使用多个装饰器,就像它们被堆叠了一样。这里要求加括号,可以使意图变得清晰,而无需施加进一步的限制和复杂语法。

2、赋值表达式不需括号

在这里,语法的选择是明确的。 PEP 572 解释了为什么需要在顶级表达式语句的周围加上括号:

加入此规则是为了简化用户在赋值语句和赋值表达式之间的选择——没有令两者都生效的语法位置。

由于赋值语句在此处无效,因此赋值表达式就不必带括号。

(译注:赋值表达式,即 Assignment Expressions 或 Named Expressions,是 Python 3.8 引入的新特性,就是它引入了新的“:=”海象操作符。)

-----------------正文分割线---------------

PEP 的全文翻译已收录在 Github 的《 PEP中文翻译计划 》中,目前已有 20+ 篇 PEP 翻译,欢迎感兴趣的同学查阅&参与翻译。

附录:

PEP614英文: https://www.python.org/dev/peps/pep-0614/

PEP614中文: http://dwz.date/RV9

PEP中文翻译计划: https://github.com/chinesehuazhou/peps-cn


以上所述就是小编给大家介绍的《Python 3.9 新特性:任意表达式可作为装饰器!》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Professional JavaScript for Web Developers

Professional JavaScript for Web Developers

Nicholas C. Zakas / Wrox / 2009-1-14 / USD 49.99

This eagerly anticipated update to the breakout book on JavaScript offers you an in-depth look at the numerous advances to the techniques and technology of the JavaScript language. You'll see why Java......一起来看看 《Professional JavaScript for Web Developers》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

html转js在线工具
html转js在线工具

html转js在线工具

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具