语法更改

在语法上，只需要一个新的语法规则

in_stmt: '@in' simple_stmt decorated

语法：http://hg.python.org/cpython/file/default/Grammar/Grammar

背景

“多行 lambda”的问题长期以来一直困扰着许多 Python 用户，并且我探索了 Ruby 的块功能后才最终理解了为什么这会让大家如此烦恼：Python 要求函数在需要它的操作之前被命名和引入，这打破了开发人员的思维流程。他们到达一个他们认为“我需要一个执行 <X> 的一次性操作”的点，并且他们不能直接说出来，而是必须回退，命名一个执行 <X> 的函数，然后从他们实际上想要在第一时间执行的操作中调用该函数。Lambda 表达式有时可以提供帮助，但它们不能替代能够使用完整块。

Ruby 的块语法也极大地启发了本 PEP 中解决方案的风格，因为它明确表明，即使限制为每个语句一个匿名函数，匿名函数仍然非常有用。考虑 Python 有多少结构，其中一个表达式负责大部分繁重的工作

• 推导式、生成器表达式、map()、filter()
• sorted()、min()、max() 的键参数
• 部分函数应用
• 提供回调（例如，用于弱引用或异步 IO）
• NumPy 中的数组广播操作

但是，直接采用 Ruby 的块语法对 Python 不起作用，因为 Ruby 块的有效性很大程度上依赖于函数定义方式中的各种约定（具体而言，使用 Ruby 的 yield 语法直接调用块以及 &arg 机制将块作为函数的最后一个参数）。

由于 Python 长期以来一直依赖于命名函数，因此接受回调的 API 的签名多种多样，因此需要一个解决方案，允许将一次性函数插入到适当的位置。

本 PEP 中采取的方法是保留显式命名函数的要求，但允许定义和引用它的语句的相对顺序更改以匹配开发人员的思维流程。其基本原理与引入装饰器时使用的基本原理相同，但涵盖了更广泛的应用。

与 PEP 3150 的关系

PEP 3150（语句局部命名空间）将其主要动机描述为将普通的赋值语句提升到与 class 和 def 语句相同的地位，其中要定义的项目的名称在计算该项目的值的详细信息之前呈现给读者。本 PEP 通过允许用其他内容（如将函数的结果赋值给值）替换标准函数定义的简单名称绑定来以不同的方式实现相同的目标。

尽管作者相同，但这两个 PEP 却直接相互竞争。PEP 403 代表了一种极简主义方法，试图通过对现状进行最少的更改来实现有用的功能。相反，本 PEP 旨在实现更灵活的独立语句设计，这需要对语言进行更大程度的更改。

请注意，在 PEP 403 更适合解释生成器表达式的行为的地方，本 PEP 能够更好地解释装饰器子句的一般行为。这两个 PEP 都支持对容器推导式的语义进行充分的解释。

关键字选择

该提案肯定需要某种前缀以避免解析歧义以及与现有结构的后向兼容性问题。它还需要向读者明确突出显示，因为它声明以下代码段将仅在执行尾随函数或类定义后才执行。

选择 in 关键字作为现有的关键字，可以用来表示前向引用的概念。

包含 @ 前缀是为了利用 Python 程序员已经习惯将装饰器语法作为乱序执行的指示这一事实，其中函数或类实际上是首先定义的，然后以相反的顺序应用装饰器。

对于函数，该结构旨在解读为“在 <引用 NAME 的此语句> 中定义 NAME 为执行 <操作> 的函数”。

类定义情况下的英语散文映射并不那么明显，但概念仍然相同。

对具有短名称的函数和类的更好的调试支持

反对广泛使用 lambda 表达式的原因之一是它们对回溯可读性和其他方面的影响。类似的反对意见针对那些促进使用短而神秘的函数名称的结构（包括此结构，它要求至少两次提供尾随定义的名称，从而鼓励使用像 f 这样的简写占位符名称）。

但是，在 PEP 3155 中引入限定名称意味着即使是匿名类和函数现在在不同的作用域中也会有不同的表示形式。例如

>>> def f():
...     return lambda: y
...
>>> f()
<function f.<locals>.<lambda> at 0x7f6f46faeae0>

同一作用域内的匿名函数（或共享名称的函数）仍然会共享表示形式（除了对象 ID 之外），但这仍然是对历史情况的重大改进，在历史情况中，除了对象 ID 之外，所有内容都相同。

可能的实现策略

与 PEP 3150 相比，本提案至少具有一项巨大的优势：实现应该相对简单。

关联的函数或类定义以及引用它的语句的 AST 中将包含 @in 子句。当存在 @in 子句时，它将代替函数或类定义通常隐含的局部名称绑定操作。

唯一可能棘手的地方是更改在 in 语句的作用域内对语句局部函数或命名空间的引用的含义，但这不应该太难解决，只需在编译器中维护一些额外的状态即可（对于单个名称处理起来要比处理完整嵌套套件中未知数量的名称容易得多）。

解释容器推导式和生成器表达式

该提议的构造的一个有趣特性是，它可以用作一个基本元素来解释生成器表达式和容器推导式的作用域和执行顺序语义。

seq2 = [x for x in y if q(x) for y in seq if p(y)]

# would be equivalent to

@in seq2 = f(seq):
def f(seq)
    result = []
    for y in seq:
        if p(y):
            for x in y:
                if q(x):
                    result.append(x)
    return result

在此扩展中，重点是解释了为什么推导式在类作用域中表现出错误行为：只有最外层的迭代器在类作用域中求值，而所有谓词、嵌套迭代器和值表达式都在嵌套作用域内求值。

生成器表达式也可以进行等效的扩展。

gen = (x for x in y if q(x) for y in seq if p(y))

# would be equivalent to

@in gen = g(seq):
def g(seq)
    for y in seq:
        if p(y):
            for x in y:
                if q(x):
                    yield x

省略装饰器前缀字符

此提案的早期版本省略了 @ 前缀。但是，如果没有该前缀，裸 in 关键字与后续的函数或类定义的关联性不够紧密。重用装饰器前缀并明确将新构造描述为一种装饰器子句，旨在帮助用户将这两个概念联系起来，并将它们视为同一想法的两个变体。

匿名前向引用

此 PEP 的早期版本（参见 [1]）提出了一个语法，其中使用 : 引入新的子句，并使用 @ 编写前向引用。对此变体的反馈几乎都是负面的，因为它被认为既难看又过于神奇。

:x = weakref.ref(target, @)
def report_destruction(obj):
    print("{} is being destroyed".format(obj))

最近的一个变体始终使用 ... 进行前向引用，以及真正匿名的函数和类定义。但是，在更复杂的情况下，这很快退化为一堆难以理解的点。

in funcs = [...(i) for i in range(10)]
def ...(i):
  in return ...
  def ...(x):
      return x + i

in c = math.sqrt(....a*....a + ....b*....b)
class ...:
  a = calculate_a()
  b = calculate_b()

使用嵌套块

使用完整嵌套套件的问题在 PEP 3150 中有最好的描述。它在实现上相对困难，作用域语义更难解释，并且会创建很多可以使用两种方法完成的事情的情况，而没有明确的指导方针来选择其中一种（因为几乎任何可以用普通命令式代码表达的构造都可以用给定语句来表达）。虽然 PEP 确实提出了一些新的 PEP 8 指导原则来帮助解决最后一个问题，但实现上的困难却不容易解决。

相比之下，此 PEP 中受装饰器启发的语法明确地将新功能限制在应该实际提高可读性而不是损害可读性的情况下。与最初引入装饰器的情况一样，这种新语法的理念是，如果它*可以*使用（即函数的局部名称绑定完全没有必要），那么它可能*应该*使用。

此想法的另一个可能的变体是保留此 PEP 的基于装饰器的*语义*，同时采用 PEP 3150 中更漂亮的语法。

x = weakref.ref(target, report_destruction) given:
    def report_destruction(obj):
        print("{} is being destroyed".format(obj))

这种方法存在几个问题。主要问题是这种语法变体使用了看起来像套件但实际上不是套件的东西。第二个问题是不清楚编译器如何知道前导表达式中的哪个名称是前向引用（尽管这可以通过在语言语法中对不是套件的套件进行适当的定义来解决）。

但是，嵌套套件尚未完全排除。 PEP 3150 的最新版本使用了显式前向引用和名称绑定方案，极大地简化了语句的语义，并且确实提供了允许定义任意子表达式而不是仅限于单个函数或类定义的优势。