摘要

在大多数支持嵌套作用域的语言中，代码可以引用或重绑定（赋值给）最近的封闭作用域中的任何名称。目前，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年，也就是 PEP 227 对嵌套作用域的支持被采纳之前，Python-Dev 上就出现了一个关于作用域语法的提案 [1]。当时，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__ import 与未知特性名称一起使用的情况。）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 变量）

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] Explicit Lexical Scoping (pre-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 进行具体编辑。

版权

本文档已置于公共领域。