一個月前（2月20日），一則新的 PEP 沒有受到任何阻礙就被官方采納了，這么快的速度，似乎並不多見。
然而，更為高效率的是，僅在半個月內，它的實現就被合入了代碼倉。也就是說，我們最快有望在 3 天后（3月23日）發布的 3.9.0 alpha 5 版本中看到它！
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