摘要

在大多数支持嵌套作用域的语言中，代码可以引用或重新绑定（赋值给）最近封闭作用域中的任何名称。目前，Python代码可以引用任何封闭作用域中的名称，但它只能重新绑定两个作用域中的名称：局部作用域（通过简单赋值）或模块全局作用域（使用global声明）。

此限制已在Python-Dev邮件列表和其他地方多次提出，并引发了广泛的讨论和许多关于如何消除此限制的提案。本PEP总结了各种建议的替代方案，以及针对每个方案提到的优缺点。

基本原理

在2.1版本之前，Python对作用域的处理类似于标准C：在一个文件中只有两个作用域级别，全局和局部。在C中，这是函数定义不能嵌套这一事实的自然结果。但在Python中，尽管函数通常定义在顶层，但函数定义可以在任何地方执行。这使得Python具有嵌套作用域的语法外观，但没有语义，并产生了令一些程序员感到意外的不一致性——例如，在顶层工作的递归函数在移动到另一个函数内部时将停止工作，因为递归函数自己的名称将不再在其主体作用域中可见。这违反了函数在放置在不同上下文中时应该保持一致的直觉。这是一个例子

def enclosing_function():
    def factorial(n):
        if n < 2:
            return 1
        return n * factorial(n - 1)  # fails with NameError
    print factorial(5)

Python 2.1通过使所有封闭作用域中绑定的名称可见，更接近静态嵌套作用域（参见PEP 227）。此更改使上述代码示例按预期工作。但是，由于对名称的任何赋值都隐式地声明该名称是局部的，因此不可能重新绑定外部作用域中的名称（除非global声明强制该名称为全局）。因此，以下代码旨在显示可以通过单击按钮递增和递减的数字，其工作方式与熟悉词法作用域的人员期望的不同

def make_scoreboard(frame, score=0):
    label = Label(frame)
    label.pack()
    for i in [-10, -1, 1, 10]:
        def increment(step=i):
            score = score + step  # fails with UnboundLocalError
            label['text'] = score
        button = Button(frame, text='%+d' % i, command=increment)
        button.pack()
    return label

Python语法没有提供方法来指示increment中提到的名称score是指在make_scoreboard中绑定的变量score，而不是increment中的局部变量。Python的用户和开发者表达了对消除此限制的兴趣，以便Python能够拥有现在许多编程语言（包括JavaScript、Perl、Ruby、Scheme、Smalltalk、带有GNU扩展的C和C# 2.0）中标准的Algol风格作用域模型的全部灵活性。

有人认为这样的功能不是必需的，因为可重新绑定的外部变量可以通过将其包装在可变对象中来模拟

class Namespace:
    pass

def make_scoreboard(frame, score=0):
    ns = Namespace()
    ns.score = 0
    label = Label(frame)
    label.pack()
    for i in [-10, -1, 1, 10]:
        def increment(step=i):
            ns.score = ns.score + step
            label['text'] = ns.score
        button = Button(frame, text='%+d' % i, command=increment)
        button.pack()
    return label

但是，此解决方法仅突出了现有作用域的缺点：函数的目的是将其代码封装在自己的命名空间中，因此程序员必须创建额外的命名空间来弥补现有局部作用域中缺少的功能，然后必须决定每个名称应该驻留在真实作用域还是模拟作用域中，这似乎是不幸的。

另一个常见的反对意见是，所需的功能可以编写为一个类，尽管有点冗长。对此反对意见的反驳是，存在不同的实现风格不是留下受支持的编程结构（嵌套作用域）功能不完整的理由。Python有时被称为“多范式语言”，因为它从其对多种编程范式的支持和优雅集成中获得了如此强大的力量、实践灵活性和教学能力。

早在1994年[1]，在PEP 227对嵌套作用域的支持被采纳之前，Python-Dev上就出现了关于作用域语法的提案。当时，Guido的回应是

这非常接近于引入CSNS[经典静态嵌套作用域]。如果你要这样做，你提出的作用域语义似乎没问题。我仍然认为CSNS的需求不足以保证这种构造……

在PEP 227之后，“外部名称重新绑定讨论”在Python-Dev上重新出现过很多次，以至于它已成为一个熟悉的事件，至少从2003年开始就以其目前的形式反复出现[2]。尽管这些讨论中提出的语言更改尚未被采用，但Guido已承认值得考虑语言更改[12]。

其他语言

为了提供一些背景信息，本节描述了一些其他语言如何处理嵌套作用域和重新绑定。

提案概述

在Python-Dev上，已经提出了许多关于如何在外部作用域中重新绑定名称的不同提案。它们都分为两类：在绑定名称的作用域中使用新语法，或在使用名称的作用域中使用新语法。

setter1 = proc { | x | y = x }      # y is local here
y = 13
setter2 = proc { | x | y = x }      # y is nonlocal here
setter1.call(99)
puts y                              # prints 13
setter2.call(77)
puts y                              # prints 77

提议的解决方案

本 PEP 提出的解决方案是在引用（内部）作用域中添加作用域覆盖声明。Guido 在 Python-Dev 上表达了对这类解决方案的偏好[14]，并且对 nonlocal 作为关键字表示认可[19]。

建议的声明

nonlocal x

防止 x 在当前作用域中成为局部名称。当前作用域中 x 的所有出现都将引用在外部封闭作用域中绑定的 x。与 global 一样，允许多个名称

nonlocal x, y, z

如果在封闭作用域中不存在预先存在的绑定，则编译器将引发 SyntaxError。（将此称为语法错误可能有点牵强，但到目前为止，SyntaxError 用于所有编译时错误，包括例如具有未知功能名称的 __future__ 导入。）Guido 曾经说过，在没有外部绑定的情况下，此类声明应被视为错误[16]。

如果 nonlocal 声明与局部作用域中形式参数的名称冲突，则编译器将引发 SyntaxError。

还允许使用简写形式，其中 nonlocal 放在赋值或增强赋值之前

nonlocal x = 3

以上与 nonlocal x; x = 3 的含义完全相同。（Guido 支持 global 语句的类似形式[24]。）

在简写形式的左侧，仅允许标识符，不允许 x[0] 之类的目标表达式。否则，允许所有形式的赋值。建议的 nonlocal 语句语法为

nonlocal_stmt ::=
    "nonlocal" identifier ("," identifier)*
               ["=" (target_list "=")+ expression_list]
  | "nonlocal" identifier augop expression_list

允许所有这些赋值形式的原因是为了简化对 nonlocal 语句的理解。将简写形式分解为声明和赋值足以理解它的含义以及它是否有效。

向后兼容性

此 PEP 以 Python 3000 为目标，正如 Guido 所建议的那样[19]。但是，其他人也注意到，本 PEP 中考虑的一些选项可能足够小，可以在 Python 2.x 中实现[26]，在这种情况下，本 PEP 可能被移动到成为 2.x 系列 PEP。

作为引入新关键字影响程度的（非常粗略的）衡量标准，以下是根据 2006 年 11 月 5 日对 Python SVN 存储库的扫描，一些建议的关键字作为标识符在标准库中出现的次数

nonlocal    0
use         2
using       3
reuse       4
free        8
outer     147

global 作为现有关键字出现 214 次。作为使用 global 作为外部作用域关键字影响程度的衡量标准，标准库中有 18 个文件将因此类更改而中断（因为函数在全局作用域中引入变量 global 之前声明了一个变量 global）

cgi.py
dummy_thread.py
mhlib.py
mimetypes.py
idlelib/PyShell.py
idlelib/run.py
msilib/__init__.py
test/inspect_fodder.py
test/test_compiler.py
test/test_decimal.py
test/test_descr.py
test/test_dummy_threading.py
test/test_fileinput.py
test/test_global.py (not counted: this tests the keyword itself)
test/test_grammar.py (not counted: this tests the keyword itself)
test/test_itertools.py
test/test_multifile.py
test/test_scope.py (not counted: this tests the keyword itself)
test/test_threaded_import.py
test/test_threadsignals.py
test/test_warnings.py

参考文献

[15] 显式词法作用域 (PEP 之前？) (Guido van Rossum) https://mail.python.org/pipermail/python-dev/2006-July/066995.html

致谢

本 PEP 中提到的想法和建议来自无数的 Python-Dev 帖子。感谢 Jim Jewett、Mike Orr、Jason Orendorff 和 Christian Tanzer 建议对本 PEP 进行具体编辑。

版权

本文档已进入公有领域。