冯·诺依曼

这样我们就可以略过对调用时省略的参数的测试。在这种方案下，通常位于最右边的位置参数和最左边的关键字参数之间的，或者在关键字参数之间的，或者在最右边的位置参数之后的那些省略掉的参数，装饰器将略过对它们的检查。现在，给定了这些限制和假设，我们可以用这一算法来考虑调用中的关键字参数以及省略的默认参数。[1] Mark Lutz. Python学习手册[M]. 机械工业出版社, 2018.个参数匹配，并且假设任何其他的参数要么是按照关键字传递并位于。个实际传递的位置参数，必须与期待的参数列表中的前。

这是有帮助的，因为在调用发生之前验证它，将会要求我们完全仿真Python的参数匹配算法一一一再一次说明，这对我们的工具来说是一个过于复杂的过程。正如我们也了解过的，Python按从左至右的顺序把按位置传递的参数值与函数头中的参数名相匹配，这样这些值就总能够匹配头部中最左边的那些名称。而关键字通过名称匹配，并且一个给定的参数只能够接收一个值。也就是说，在一个调用中，一个非关键字参数通常不会跟在一个关键字参数后面，并且在定义中，一个非默认参数不会跟在一个默认参数后面。这两种位置中，所有的。

为了完全地通用，原则上我们可以完整模拟Python的参数匹配逻辑，来看看哪个名称以何种模式传入，但是这对于我们的工具来说太复杂了。如果我们能够设法根据所有期待参数的名称集合来匹配按照名称传人的参数，从而判断哪个位置参数真正地出现在给定的调用中，那将会更好。在函数对象上以及与其关联的代码对象上可用的内省API恰好拥有我们所需的工具。期待的参数名集合只是附加到函数的代码对象上的前。[1] Mark Lutz. Python学习手册[M]. 机械工业出版社, 2018.

之前的文章中的版本说明了我们需要使用的基础知识，但是它非常局限一一它只支持验证按照位置传递的参数，而不支持验证关键字参数（实际上，它假设不会有那种使得参数位置数不正确的关键字参数传递）。当这段脚本运行的时候，超出范围的参数会像前面一样引发异常，但参数可以按照名称或位置传递，并且省略的默认参数不会验证。通过把被包装函数的期待参数与调用时实际传入的参数匹配，它就能够同时支持验证位置参数和关键字参数，并且它会跳过对调用中忽略的默认参数的测试。简而言之，要验证的参数通过装饰器的关键字参数说明，装饰器随后遍历。

为了简化步骤，起初我们将编写一个只对位置参数有效的装饰器，并且假设这些参数在每次调用中总是出现在相同的位置。算是老调重弹，这段代码略微修改了我们前面介绍的编程模式：我们使用装饰器参数、嵌套作用域来进行状态保持等等。的时候，装饰器返回未修改的最初函数，以避免额外调用及其相关的性能损失。在这个例子中，范围测试中的参数数目从1开始，而不是从0开始。中的第一项接受主体类的实例，并且将其传递给最初的方法函数中的。就像在前面的文章中学习到的，我们还使用了嵌套的def。优化命令行标志运行它（例如。

对于更为复杂的情况，这可能很繁琐（假设试图内联代码来实现之前的文章中的装饰器所提供的属性私有。作为装饰器工具的一个示例，本文开发了一个函数装饰器，它自动地检测传递给函数或方法的参数是否在有效的数值范围内。需要注意的是，我们这里的目标和前面编写的属性验证不同。这里我们想要验证传入的函数参数的值，而不是进行设置的属性值。Python的装饰器和内省工具允许我们很容易地实现这一新的任务。一种更为有用和有趣的替代方案是，开发一个通用的工具来自动为我们执行范围测试，针对我们现在或将来要编写的任何函数或方法的参数。

属性声明，必须再次提醒，像这样为类添加访问控制不完全是Python的风格。实际上，除了充当装饰器使用的一个展示，大多数程序员很可能发现这一示例基本上或者完全不重要。大多数大型的Python程序没有任何这样的控制也同样获得成功。也就是说，在开发过程中我们会发觉这一工具在有限的领域较为有用。如果我们确实想要控制属性访问以杜绝编程错误，或者恰好将要成为前C++或前Java程序员，那么使用Python的运算符重载和内省工具，大多数事情是可以完成的。既然我已经用如此大的篇幅实现了Python代码的。

这里，我们不会进一步介绍这一选项的编程模式，因为我们将在后面的文章中连同元类，学习类扩展技术。这可能最终产生一个解决方案一一例如将私有属性作为或描述符来实现，它们检查栈并只对外部的访问进行验证，但是它可能会进一步减慢访问，并且其内部对我们来说过于复杂，就像是黑魔法，无法在此探索。尽管在包装器中冗余地定义运算符重载方法可能是前面介绍的Python3.X难题的最直接的权宜之计，但它不是唯一的方法。这些插人的方法使用我们在前面的文章学习过的技术，将会把有效的请求向上传递到其父类以避免循环。在我们的例子中，如果。

然而在通常的情形下，为容纳Python3.X的新式类作为委托代理，需要有充分大量的额外代码一一原则上讲，每一个不再作为普通实例属性自动分发的运算符重载方法，都将需要在通用工具类中繁冗地定义，就像这个私有装饰器一样。这就是为什么我们的代码中省略了这一扩展：潜在地有50多种这样的方法！因为其全部类都是新式的，所以基于委托的代码在Python3.X中会更加有难度，尽管不是必然不可实现。通常接口代理被要求添加对运算符重载方法的支持，以便正确地委托调用。然而，在我们特定的私有应用中，它也引起了一些额外的设计选择。

自然地，之前的文章中的两个混合器父类变体都可以通过代码的一些额外变化来改进。其次，所有前置的内置混合类显式地编写了每个运算符重载方法，并截获了由运算发出的调用。有了替代代码，我们就能够从一个名称表单中机械地生成方法，并且通过创建类级别的描述符来仅仅截获调用前的属性获取一一正如在下面的代码中所做的，就像第二个混合替代方案，其假设被代理的对象在代理实例自身中被命名为。示例客户端在Python2.X和Python3.X下都能正确地工作，重载了索引和调用的子类也一样工作。

作为另一种选择，这些方法可以通过常见的父类进行插人一一考虑到有几十种这样的方法，一个外部类也许更适合这个任务。就像内联的解决方案，在代理任意对象接口的通用工具中，这两个混合类也要求为每个内置操作定义一个方法。两个父类混合器中的任一个都将是外来的代码，但是必须只被实现一次。它们似乎比基于元类和装饰器的多样化工具的方案更加清楚直接，我们会在网上找到这些使用必备方法千篇一律地填充每个代理类的工具。[1] Mark Lutz. Python学习手册[M]. 机械工业出版社, 2018.

正如前面的文章所提到的，Python3.X中最直接的解决方案是：在像装饰器这样的基于委托的类中，重新定义可能在内嵌对象中出现的运算符重载名称。这种方法并不理想，因为它产生了一些代码冗余，特别是与Python2.X的解决方案相比较时。然而，这不是一项不能实现的编码工作；在某种程度上可以使用工具或父类来自动完成；它足以使我们的装饰器在Python3.X下工作；例如，下面的代码是一种内联重定义手段一一为被包装对象可能自己定义的每一个运算符重载方法的代理添加方法重定又，来捕获和委托。

然而在Python3.X中，因为所有的类都自动（并强制）是新式类，所以如果它们由内嵌对象来实现，这样的方法将会失效一一一因为它们没有被代理捕获，所以不会被继续传递。正如我们在之前的文章所了解到的，内置操作在经典类的实例中查找运算符重载名称，但在新式类的实例中不会这么做一一对于后者，它们完整地跳过实例并在类中搜索这样的方法。因此，内置操作隐式运行的。然而下面显示的是在Python3.X中运行的结果，虽然其在Python2.X中不汇报出任何错误，但同样的代码在Python3.X下运行的时候，隐式调用的。

正如编写的那样，当在Python2.X下运行时，代理类是一个经典类，但是当在Python3.X下运行时，代理类是一个新式类。同样地，在Python2.X中代码支持任何客户端类，但是在Python3.X中代码不能够验证或委托由内置操作隐式分发的运算符重载方法，除非它们在代理中被重新定义。不使用运算符重载的客户端是被完整支持的，但是其他的客户端在Python3.X中可能需要额外的代码。因为被包装对象的类的本质是与代理无关的，所以我们只考虑代理自己的代码，它在Python2.X下运行，而不是Python3.X。

不用装饰器，我们也可以实现同样的结果，通过使用管理器函数或者手动编写装饰器的名称重绑定；这一方法以及任何其他基于包装器的方法的主要潜在缺点是：属性访问导致额外调用，并且被装饰类的实例并不真的是最初的被装饰类的实例一一一例如，如果你用。除非你计划在对象类型上进行内省，否则类型问题可能是不相关的，并且额外的调用可能基本上适合开发时段；属性冲突的风险，并且它在类似这样的通用工具中也可以发挥优势。尽管上文的例子确实实现了对一个实例及其类的属性的访问控制，但还是可能以各种方式破坏这些控制一一例如通过显式地检查。

所使用的测试函数保存在一个额外的外层作用域中。再一次，我们可以自己研究这些代码并体验它们是如何工作的。它们本质上相反，尽管不是由类方法创建的未声明名称行为略有不同一一新的名称可以赋值并且由此从类的外部在。声明的反过程，因此我们只需要取消内部测试。本文列出的示例允许一个类使用装饰器来定义一组。之下创建（所有未声明的名称都是可以访问的），但不能在。下创建的（所有未声明的名称都是不可访问的）。声明是有意被设计为相互排斥的：当使用了。，所有未声明的名称都被认为是。，所有未声明的名称都被认为是。

通过只为它自己设定一个命名空间字典，并且为被包装的对象使用存储中立的工具，包装器类就可以避免其他工具中的内在局限。正如我们在之前的文章中所了解到的，这一方法不能在没有循环的情况下直接赋值一个属性。的属性，所以我们的装饰器应用于使用任何一种存储方案的类。和相似的工具：在被包装实例中委托的名称会被重新查找，而与装饰器代理对象自己的属性无关。用来获取被包装对象中的属性，因为它们可能存储在对象自身中或者由对象继承。字典，而不是在被包装的实例中，因此这一担忧并不适用。字典来设置被包装对象自身之中的属性。

1] Mark Lutz. Python学习手册[M]. 机械工业出版社, 2018.》中使用的类装饰器接受任意多个参数来命名私有属性。然而真正发生的情况是，参数传递给了。返回了应用于主体类的装饰器函数。也就是说，在装饰发生之前使用这些参数。返回装饰器，装饰器反过来把私有的列表作为一个外层作用域引用来“记住"。由于Python的作用域和命名空间规则，这些都很自然地工作。

对来自主体对象外部的属性访问，由包装器层的重载方法拦截，如果访问合法的话，就委托给类。来自类自身内部的（例如，通过其方法代码内的self进行的）访问没有被拦截，并且允许不经恰查的常规运行，因为这一版本中没有继承私有的属性。然而，继承使得这很困难，因为辨别来自类内部与来自类外部的访问不是很直接的（应该允许内部访问的常规运行，并应该限制外部访问）。为了解决这个问题，《系统学习Python——运算符重载》系列文章中的示例需要继承的类使用。》中的代码有点复杂，并且你最好自己跟踪运行它，看看它是如何工作的。

它不接受从被装饰类的外部对这样的属性的获取和修改访问，但是它仍然允许类自身在其自己的方法中自由地访问那些名称。它不是具体的C++或Java，但它提供了类似的访问控制作为Python中的选项。实际在某种意义上，这只是我们前面遇到的属性跟踪器类装饰器的一个扩展。尽管这个示例利用了类装饰器的新语法糖来编写私有属性，但它的属性拦截最终仍然是基于我们在前面各章介绍的。注意装饰器是如何捕获和验证在被包装类之外运行的属性获取和赋值的，但是它却没有捕获类自身内部的属性访问。如下的类装饰器实现一个用于类实例属性的。

例如，函数装饰器也可能用来处理函数属性，并且类装饰器可能动态地插人新的类属性，甚至新的方法。因为装饰器通过装饰器代码来运行新的函数和类，从而有效地工作，它们也可以用来管理函数和类对象自身，而不只是管理对它们随后的调用。当这段代码运行的时候，被装饰的对象按照名称添加到注册表中，但当随后调用它们的时候，它们仍然按照最初的编写方式工作，而没有指向一个包装器层。这样的装饰器直接扩展了函数和类，但没有捕捉对它们的随后调用。我们将在后面的文章见到多的管理类的类装饰的例子，因为这证明了它已经转向了元类的领域。

对于大多数程序来说，装饰的统一性是一笔财富，类型差异不太重要，并且额外调用对速度的影响也不显著。此外，只有当使用包装器的时候才会产生这其中的后一个问题，如果需要最佳性能我们可直接删除装饰器来解决，但添加包装逻辑的非装饰器解决方案也会导致额外调用的问题。》开始的时候提到的，装饰器展示给我们利弊权衡。尽管语法意义重大，当面对新工具的时候，我们通常都忘了问“为什么要使用”的问题。既然我们已经看到了装饰器实际是如何工作的，在我们继续前进学习更多的代码之前，让我们后退一些，花点时间在这里看看更大的图景。

来拦截对包装的和内嵌实例对象的获取。正如我们在前面见到的，我们真正需要完成的只是把实例创建调用移入一个类的内部，而不是把实例传递一个管理器函数。基本上，类装饰器把特殊语法要求从实例创建调用迁移到了类语句自身。这对于我们前面所编写的跟踪器那样的函数装饰器也是成立的。像这样的管理器函数的方法把使用特殊语法的开销放到了调用上，而不是期待在函数和类定使用饰语法，但是它也允许我们在逐一调用的基础卜有选择地应用扩增。[1] Mark Lutz. Python学习手册[M]. 机械工业出版社, 2018.

这里的问题是一个糟糕的状态保持一一一我们为每个类创建了一个装饰器实例，但是不是针对每个类实例，这样一来，只有最后一个实例的状态信息被保持住了。就像我们在前面处理对方法进行装饰的类错误一样，其解决方案在于放弃基于类的装饰器。令人奇怪的是，使用正确的运算符重载协议，这个例子中的装饰器函数几乎可以编写为一个类而不是一个函数。正如我们在前面见到的，这个仅针对类的替代方法像前面一样处理多个类，但是它对于一个给定的类的多个实例并不是很有效：每个实例构建调用会触发。由于同样的原因，最初的非装饰器版本正确地处理多个实例。

还要注意前面的代码装饰了一个用户定义的类，我们也可以使用装饰器包装一个像列表这样的内置类型，只要我们通过子类化来允许装饰器语法，或者手动地执行装饰一一装饰器语法要求每一。在Python3.X的类中，类实例会从类中继承这些方法中的一些，而不是继承全部的默认形式（实际上，是从。Private`装饰器中再次看到该方法的作用一一一那里我们还将学习在Python3.X中添加这样的代码所需要的方法的途径。假设我们将会产生类的多个实例，并且想要扩增类的每一个实例，装饰器通常将会在代码大小和代码可维护性上取得双赢。

准确地说，它跟踪在被包装对象的类之外发出的属性访问。在被包装对象的内部访问其方法不会被捕获，并且会按照设计正常运行。这种整体接口模型和函数装饰器的行为不同，装饰器只包装一个特定的方法。类装饰器基本上可以在实例上安装一个包装器或“代理"逻辑层，以某种方式管理对其接口的访问。我们在之前的文章中介绍的管理的属性中看到过类似的例子。当获取未定义的属性名的时候，我们可以使用这个钩子来拦截控制器类中的方法调用，并将它们传递给一个嵌人的对象。类拦截了对任何被包装对象的命名属性的访问，打印出一条跟踪信息，并且使用内置数。

语句（仅在Python3.X中可用）来改变外层作用域名称，我们在这里可以编写一个自包含程度更高的解决方案一一一下面的替代方案为每个类使用了一个外层作用域，而不是为每个类使用一个全局表入口，并实现了同样的效果。下面代码中的第二段为每次装饰使用一个实例，而不是使用一个外层作用域、函数对象或全局表。实际上，第二段代码依赖于相同的编程模式，随后我们会看到这是一个常见的装饰器类错误。在Python3.X或Python2.X（2.6及之后的）版本中，我们也可以用函数属性或类编写一个自包含的解决方案。

在前面的文章中，我们已经编写了函数装饰器来管理函数调用，但是正如我们已经见到的，从Python2.6和Python3.0起装饰器已被扩展，因此也能在类上使用。如同前面所提到的，尽管类装饰器与函数装饰器在概念上很相像，但类装饰器是在类上使用的一一它们可以用于管理类自身，或者用来拦截实例创建调用以管理实例。和函数装饰器一样，类装饰器其实只是可选的语法糖，尽管很多人相信，它们使得程序员的意图更为明显并且能使不正确的调用或错失的调用最小化。这段代码实现了传统的单例编程模式，其中每个类最多只有一个实例存在。

需要注意的是，本文的计时器装饰器在任何函数上都有效，但是，要将其应用于类级别的方法上，需要进行细小的改写。简而言之，正如我们在前面文章《》中所介绍的，必须避免使用一个嵌套的类。由于这一变化被故意保留来作为我们本章末尾测试题的一个主题，因此在这里我们暫时不会给出完整的解答。这个为函数计时的装饰器可以用于模块中和交互式命令行下的任何函数。换言之，它作为一种多用途工具，自动获得了作为脚本中计时代码的资格。[1] Mark Lutz. Python学习手册[M]. 机械工业出版社, 2018.

前面文章介绍的计时器装饰器有效运行，但是如果它可配置性更强的话，就会更好一一一例如提供一个输出标签并且可以打开或关闭跟踪消息，这些在一个多用途工具中可能很有用。装饰器参数在这里派上了用场：对它们适当编写后，我们可以使用它们来指定配置选项，每个被装饰的函数都可以有各自的选项。的一个实例，它记住被装饰函数自身，而且还能访问位于外围函数作用域中的装饰器参数。返回的装饰器，它既记住了装饰器参数又记住了最初的函数，并且返回一个可调用的。函数，它们的外层作用域保留的状态与具体的装饰器相关。类作为实际的装饰器。

在Python3.X中也是一个迭代器，但是Python2.X和Python3.X的结果不能直接比较，除非你还将这一调用提升到计时代码的外部。，而在Python2.X中使用一个无操作函数简单地返回它的输人参数，保持其不变。这会在Python2.X中增加一个非常小的常量时间，被计时函数中的内层循环迭代所花费的时间很可能掩盖它。内置函数在Python3.X中返回一个按需求生成结果的可迭代对象，但是在Python2.X中返回一个实际的列表。最后，正如我们之前为跟踪器装饰器所做的，我们可通过在文件底部的一个。

另一方面，因为装饰器使用扩增逻辑掌控对函数的每一次调用，如果你想要更有选择性地扩增调用，一个非装饰器的方法也许会更好。为方便比较，我们可以使用一个非装饰器方法，可作为计时迭代的替代方案。此外，在非装饰器方案中，可能没有直接的方法来保证一个程序中的所有列表构造器调用可以通过计时器逻辑发送，在找到所有签名并潜在地修改它们方面有所不足。在这个特定的例子中，一种非装饰器的方法允许主体函数带有或不带有计时，但是当需要计时的时候，它也会使调用签名变得复杂一一一我们需要在每次调用的时候添加代码，而不是在。

为了展示函数装饰器的多样化能力，让我们来看一种不同的用例。接下来的装饰器将对被装饰数的调用进行计时一一既有单次调用的用时，也有全部调用的总时间。当然了，计时时间随Python系列和测试机器而变化。这里的累计时间作为一个可用的类实例属性出现。通常，当列表推导中没有函数调用时，[1] Mark Lutz. Python学习手册[M]. 机械工业出版社, 2018.调用几乎比它慢两倍（也可以说，对函数调用的需求使其变慢）。

类装饰器和元类这两种方案都可以用来扩展一个类或返回一个任意的对象来替代它一一一这是一种几乎拥有无限的、基于类的定制化可能性的协议。我们后面会看到，元类也可以定义处理它们实例类的方法，而不是这些实例类的普通实例一一这是一种和类方法很相似的技术，而且可以用类装饰器代理中的方法和数据来模拟实现，或者甚至是一个返回一个元类实例的类装饰器。事实上，一个元类完全可以不必是一个类。类装饰器也可以扩展类自身，或者返回一个拦截了随后的实例创建调用的代理对象。为了获得对一个新的类对象创建或初始化的控制，一个元类通常重新定义。

例如，通过使用带有外层作用域状态的内嵌函数，而不是带有属性的可调用类实例，函数装饰器通常能变得更加广泛地适用于类一级的方法。不过作为一个快速的示例，让我们看看一个简单的用户定义的装饰器的应用。下面的代码通过这种方式定义了一个调用代理类，在实例中储存被装饰的函数，并捕获对原来嵫数名的调用。这个装饰器对于任何接受基于位置参数的函数都有效，但是它不能处理关键字参数，而且不能装饰类一级的方法函数（简而言之，对于其。正如我们将在前面的文章中见到的，有各种各样的方式来编写函数装饰器，包括嵌套。方法方法将只传人一个。

它们可以在装饰语法中使用，只是因为它们把一个函数当作参数并且返回一个可调用对象，而原来的函数将与该对象重新绑定。实际上，任何这样的函数都可以通过这种方式使用，也包括后面的文章将会介绍的我们自己编写的用户定义函数。因为装饰器会返回任何种类的对象，这也可以让装饰器在每次调用时都增加一层逻辑。装饰器函数可以返回原来的函数本身，或者一个新的代理对象，该代理对象用于保存传给装饰器的原来的函数，原来的函数将会在额外逻辑层执行后间接地运行。从语法上来讲，函数装饰器可以被看作是它后边跟着的函数的运行时声明。

静态方法和类方法都能扮演其他高级的角色，我们将在这里略过。在最近的Python版本中，随着函数装饰语法的出现，静态方法和类方法的指定都变得更加简单。装饰语法是把一个函数应用于另一个函数的一种方式，该语法有着比最开始的静态方法用例更广的用法。装饰语法允许我们在Python2.X和Python3.X中扩展类。例如，初始化上一个示例中。例如，需要为每个类管理实例计数器的代码，可能最好采用类方法。[1] Mark Lutz. Python学习手册[M]. 机械工业出版社, 2018.这样的计数器的数据。

上一篇文章使用了静态方法对类生成的对象计数，实际上，类方法也可以实现类似的效果一一一如下代码与前面列出的静态方法版本具有相同的行为，但是它使用一个类方法来把实例的类接收到其第一位参数中。不过当使用类方法的时候，别忘了它们接收调用的主体的最具体（最底层）的类。当试图通过传入类来更新类数据的时候，这具有某些细微的隐藏含义。通过直接编写自己的类名来更新其数据可能会更好，而不是依赖于传人的类参数。子类的一个实例进行了一次类方法的调用，并且Python传人了最底层的类。如果该方法试图赋值传人的类的数据，那么它将更新。

然而，采用静态方法可以把函数名变成类作用域内的局部名称（从而不会和模块内的其名称冲突）；同时还能让子类通过继承来定制静态方法一一一这是比从父类编写的文件中导人函数更方便的一种方式。现在，有了前文的这些内置函数，如下的实例统计示例的静态方法等价形式。通过使用静态方法内置函数，我们的代码现在允许在Python2.X和Python3.X中通过类或其任何实例来调用无。直接移到类外部的做法（如前面的文章所做的）相比较，这个版本需要一个额外的。调用（或者我们在后面的文章将会看到的一行。

此外，Python3.X也允许类中的简单函数只在通过一个类对象调用的时候充当静态方法的角色，而不需要额外的协议，从而扩展了这一模式。除了前面文章中提到的之外，目前还有另一个选择，可以编写和类相关联的、能通过类及其实例被调用的简单函数。从Python2.2起，我们可以编写带有静态方法和类方法的类，两者在调用时都不需要传人实例参数。内置方法还可以允许这样的方法在Python3.X中通过一个实例调用，而在Python2.X中同时可以通过类和实例调用（也就是说，前者在Python3.X中没有。