Python 中的 LEGB 规则决定了变量和函数的作用域解析顺序。它代表了四个作用域层级：

• 局部作用域
• 闭包函数外的函数
• 全局作用域
• 内置作用域

局部作用域

局部作用域是最狭窄的作用域。它指的是函数或代码块内部定义的变量。局部变量只能在定义它们的函数或代码块内访问。

    
      deflocal_scope_example():
        x = 10   局部变量
        print(x)   输出局部变量 x 的值

      local_scope_example()
    
  

闭包函数外的函数

闭包函数外的函数作用域指的是定义在函数内部但不在任何嵌套函数内的变量。它可以被该函数内的所有代码块访问，包括嵌套函数。

    
      def enclosing_scope_example():
        x = 10   外部函数的变量

        def inner():
          print(x)   输出外部函数的变量 x 的值

        inner()

      enclosing_scope_example()
    
  

闭包与自由变量

之前 分析了装饰器的语法，由此可以直接推导出其基本框架。但为了写出一个功能完整的装饰器，还需要了解一个概念——闭包。

闭包(closure) ，是引用了自由变量的函数。 这个被引用的自由变量将和这个函数一同存在，即使已经离开了创造它的环境也不例外。

看下面的例子

对f内部的函数g来说，参数a既不是它的参数，也不是它的局部变量，而是它的自由变量。该自由变量可以

闭包和嵌套函数的概念有所区别。闭包当然是嵌套函数，但没有引用自由变量的嵌套函数却不是闭包。

Python 的函数有一个只读属性__closure__ ，存储的就是函数所引用的自由变量，

如果仅仅是嵌套函数，它的__closure__应该是None 。

闭包有个重要的特性：内部函数只能引用而不能修改外部函数中定义的自由变量。试图直接修改只有两种结果，要么运行出错，要么你以为你修改了，实际并没有。

不能修改不是因为 Python 设计者故意限制，不给它权限，而是外部的自由变量被内部的局部变量覆盖了；被覆盖了也不是闭包独有的特性，从普通函数内部同样也不能直接修改全局变量。Python 命名空间的查找规则简写为 LEGB，四个字母分别代表 local、enclosed、global 和 build-in，闭包外层函数的命名空间就是 enclosed。Python 在检索变量时，按照 L -> E -> G -> B 的顺序依次查找，如果在 L 中找到了变量，就不会继续向后查找。

在示例 1 中，你的本意是修改自由变量number，然而并不能：由于存在对number的赋值语句（number += 1），Python 会认为number是printer的局部变量，可是在局部变量字典中又查找不到它的定义，只好抛出异常。抛出的异常不是因为不能修改自由变量，而是局部变量还没赋值就被引用了。

在示例 2 中，Python 成功地在printer内定义了局部变量number ，并覆盖了同名自由变量，你可能以为自己成功修改了print_msg中的number ，然而并没有。

怎么才能修改呢？

一种做法是利用可变类型(mutable)的特性，把变量存放在列表(List)之中。对可变的列表的修改并不需要对列表本身赋值， number[0] = 3只是修改了列表元素。虽然列表发生了变化，但引用列表的变量却并没有改变，巧妙地“瞒”过了 Python。见示例3。

Python 3 引入了nonlocal关键字，明确告诉解释器：这不是局部变量，要找上外头找去。在示例 4 中， nonlocal帮助我们实现了所期望的对自由变量的修改。

其实，在 Python 2 中，用global代替nonlocal ，也能达到类似的效果，但由于全局变量的不易控制，这种做法不被提倡。

下面的例子很好地展示了自由变量的特点：与引用它的函数一同存在，而想要修改它，得小心谨慎。

装饰器rate_limit的作用，是限制被装饰的函数每秒内最多被访问max_per_sec次。为此，需要维护一个变量用以记录上次被调用的时刻，它独立于函数之外，和被修饰的函数一同存在，还能在每次被调用的时候更新。 last_time_called就是这样的变量。为了正确地更新， last_time_called以列表的形式存在。如果在 Python 3 中，它也可以直接存为float ，只要在内部函数中声明为nonlocal ，也可以达到同样的目的。

“Python”有什么缺点？

python的整个系统，我其实有非常多的不满。 但是用任何一门语言都是取舍问题，如果有一门语言，库够多，已读，易用，性能高，我毫不犹豫立刻转过去。 python的强处在于庞大的库，还有非常好的易读和易用性。 但是相比来说，性能一直是个问题。 python的实现性能大约和C相差五倍上下。 如果是大规模计算问题，大约能差10倍以上。 当然，我们可以写C扩展，但是这就不是使用python了。 我们也可以说，很多时候我们不需要这么快的速度。 这是个事实，但是不改变python性能差的事实。 python不但性能差，还有GIL这个玩意。 以至于我现在对高并发计算都采取多进程的模式。 多进程模式的通讯效率肯定比多线程低，而且麻烦。 另外，python在底层设计上，也表现出很强的实用主义倾向。 这是比较外交术语的词汇，更加直白的说法应当是，混乱，不知所谓。 在闭包设计上采用free variable设计，而不是lisp中的environs设计。 区别？你试试看在外层闭包中from lib import *。 由于引入不定个数名称，free variable无法处理。 类似的问题还有LEGB规则，新手往往要花很长时间研究这个例子究竟是怎么错的： a = 1 def f(): print a a = 2 我勒个去，这种反直观反人类的事情都有，还敢说自己易读。