What are decorators in Python? How do decorators work?

Python introduced decorators very early on - in PEP-318, as a mechanism to simplify the way functions and methods are defined that must be defined after their initial definition. Revise.

One of the original motivations for doing this was to use functions such as classmethod and staticmethod to transform the original definition of a method, but they require an extra line of code to modify the function's initial definition.

Generally speaking, every time a transformation must be applied to a function, we must call it with the modifier function and then reassign it to the name when the function was initially defined.

For example, suppose there is a function called original, and there is a function on it that changes the original behavior (called modifier), then we must write like this:

def original(...):
    ...
original = modifier(original)

(Related free learning Recommended: python video tutorial)

Please note how we changed the function and reassigned it to the same name. This is confusing, error-prone (assuming someone forgets to reassign the function, or reassigns the function, but not on the line after the function definition, but somewhere further), and cumbersome. For this reason, the Python language has added some syntax support.

The previous example can be rewritten as follows:

@modifier
def original(...):
   ...

This means that the decorator is just syntax sugar for the content after calling the decorator as the first parameter of the decorator itself, and the result will be what the decorator returns.

To be consistent with Python's terminology, in our example modifier is called a decorator, and original is a decorating function, often also called a wrapper object.

While the feature was originally thought of as being for methods and functions, the actual syntax allows it to decorate any type of object, so we'll look at decorators applied to functions, methods, generators, and classes.

One last thing to note is that while the name of the decorator is correct (after all, the decorator is actually changing, extending, or processing the wrapped function), do not compare it to the decorator design pattern Confused.

5.1.1 Decorator functions

Functions are probably the simplest representation of Python objects that can be decorated. We can use decorators on functions to apply all kinds of logic - we can validate parameters, check preconditions, completely change the behavior, modify its signature, cache the results (create an in-memory version of the original function), etc.

For example, we will create a basic decorator that implements the retry mechanism, controls a specific domain-level exception and retries a certain number of times:

# decorator_function_1.py
class ControlledException(Exception):
    """A generic exception on the program's domain."""

def retry(operation):
    @wraps(operation)
    def wrapped(*args, **kwargs):
        last_raised = None
        RETRIES_LIMIT = 3
        for _ in range(RETRIES_LIMIT):
            try:
                return operation(*args, **kwargs)
            except ControlledException as e:
                logger.info("retrying %s", operation.__qualname__)
                last_raised = e
        raise last_raised

    return wrapped

The use of @wrap can be ignored for now, because it Will be discussed in another section. Using "_" in a for loop means that the number is assigned to a variable that we are not interested in at the moment because it is not used in the for loop (in Python it is a common thing to name ignored values ​​"_" Idiom).

The retry decorator does not receive any parameters, so it can be easily applied to any function as follows:

@retry
def run_operation(task):
    """Run a particular task, simulating some failures on its execution."""
    return task.run()

As explained at the beginning, on top of run_operation @retry The definition is just syntactic sugar provided by Python for actually executing run_operation = retry(run_operation).

In this limited example, we can see how to use a decorator to create a generic retry operation that, under certain determined conditions (in this example, expressed as a possible timeout-related exception) , which will allow the decorated code to be called multiple times.

5.1.2 Decoration classes

Classes can also be decorated (PEP-3129), and their decoration methods are the same as those of syntax functions. The only difference is that when writing the code for the decorator we have to take into account that what is received is a class and not a function.

Some practitioners may think that decorating a class is quite a complicated matter, and such a scenario may harm readability because we will declare some properties and methods in the class, but behind the scenes, the decorator may Apply some changes, thus rendering a completely different class.

This assessment is correct, but it only holds true when decorative technology is seriously abused. Objectively, this is no different from decorating functions; after all, classes, like functions, are just one type of object in the Python ecosystem. We'll look at the pros and cons of this issue again in Section 5.4, but here we'll just explore the pros of decorators, especially those that apply to classes.

(1) All the benefits of reusing code and the DRY principle. A useful case for class decorators is to force multiple classes to conform to a specific interface or standard (by making only one check in the decorator that will be applied to multiple classes).

(2) You can create smaller or simpler classes - these classes will later be enhanced by decorators.

(3) If you use decorators, the conversion logic that needs to be applied to a specific class will be easier to maintain without using more complex (usually discouraged) methods such as metaclasses.

在装饰器的所有可能应用程序中，我们将探索一个简单的示例，以了解装饰器可以用于哪些方面。记住，这不是类装饰器的唯一应用程序类型，而且给出的代码还可以有许多其他解决方案。所有这些解决方案都有优缺点，之所以选择装饰器，是为了说明它们的用处。

回顾用于监视平台的事件系统，现在需要转换每个事件的数据并将其发送到外部系统。然而，在选择如何发送数据时，每种类型的事件可能都有自己的特殊性。

特别是，登录事件可能包含敏感信息，例如我们希望隐藏的凭据。时间戳等其他领域的字段可能也需要一些转换，因为我们希望以特定的格式显示它们。符合这些要求的第一次尝试很简单，就像有一个映射到每个特定事件的类，并知道如何序列化它那样：

class LoginEventSerializer:
    def __init__(self, event):
        self.event = event

    def serialize(self) -> dict:
        return {
            "username": self.event.username,
            "password": "**redacted**",
            "ip": self.event.ip,
            "timestamp": self.event.timestamp.strftime("%Y-%m-%d
             %H:%M"),
        }

class LoginEvent:
    SERIALIZER = LoginEventSerializer

    def __init__(self, username, password, ip, timestamp):
        self.username = username
        self.password = password
        self.ip = ip
        self.timestamp = timestamp

    def serialize(self) -> dict:
        return self.SERIALIZER(self).serialize()

在这里，我们声明一个类。该类将直接映射到登录事件，其中包含它的一些逻辑——隐藏密码字段，并根据需要格式化时间戳。

虽然这是可行的，可能开始看起来是一个不错的选择，但随着时间的推移，若要扩展系统，就会发现一些问题。

（1）类太多。随着事件数量的增多，序列化类的数量将以相同的量级增长，因为它们是一一映射的。

（2）解决方案不够灵活。如果我们需要重用部分组件（例如，需要把密码藏在也有类似需求的另一个类型的事件中），就不得不将其提取到一个函数，但也要从多个类中调用它，这意味着我们没有重用那么多代码。

（3）样板文件。serialize()方法必须出现在所有事件类中，同时调用相同的代码。尽管我们可以将其提取到另一个类中（创建mixin），但这似乎没有很好地使用继承。

另一种解决方案是能够动态构造一个对象：给定一组过滤器（转换函数）和一个事件实例，该对象能够通过将过滤器应用于其字段的方式序列化它。然后，我们只需要定义转换每种字段类型的函数，并通过组合这些函数创建序列化器。

一旦有了这个对象，我们就可以装饰类以添加serialize()方法。该方法只会调用这些序列化对象本身：

def hide_field(field) -> str:
    return "**redacted**"

def format_time(field_timestamp: datetime) -> str:
    return field_timestamp.strftime("%Y-%m-%d %H:%M")

def show_original(event_field):
    return event_field

class EventSerializer:
    def __init__(self, serialization_fields: dict) -> None:
        self.serialization_fields = serialization_fields

    def serialize(self, event) -> dict:
        return {
            field: transformation(getattr(event, field))
            for field, transformation in
            self.serialization_fields.items()
        }

class Serialization:
    def __init__(self, **transformations):
        self.serializer = EventSerializer(transformations)

    def __call__(self, event_class):
        def serialize_method(event_instance):
                return self.serializer.serialize(event_instance)
            event_class.serialize = serialize_method
            return event_class

@Serialization(
    username=show_original,
    password=hide_field,
    ip=show_original,
    timestamp=format_time,
)
class LoginEvent:

    def __init__(self, username, password, ip, timestamp):
        self.username = username
        self.password = password
        self.ip = ip
        self.timestamp = timestamp

注意，装饰器让你更容易知道如何处理每个字段，而不必查看另一个类的代码。仅通过读取传递给类装饰器的参数，我们就知道用户名和IP地址将保持不变，密码将被隐藏，时间戳将被格式化。

现在，类的代码不需要定义serialize()方法，也不需要从实现它的mixin类进行扩展，因为这些都将由装饰器添加。实际上，这可能是创建类装饰器的唯一理由，因为如果不是这样的话，序列化对象可能是LoginEvent的一个类属性，但是它通过向该类添加一个新方法来更改类，这使得创建该类装饰器变得不可能。

我们还可以使用另一个类装饰器，通过定义类的属性来实现init方法的逻辑，但这超出了本例的范围。

通过使用Python 3.7+ 中的这个类装饰器（PEP-557），可以按更简洁的方式重写前面的示例，而不使用init的样板代码，如下所示：

from dataclasses import dataclass
from datetime import datetime

@Serialization(
    username=show_original,
    password=hide_field,
    ip=show_original,
    timestamp=format_time,
)
@dataclass
class LoginEvent:
    username: str
    password: str
    ip: str
    timestamp: datetime

5.1.3　其他类型的装饰器

既然我们已经知道了装饰器的@语法的实际含义，就可以得出这样的结论：可以装饰的不仅是函数、方法或类；实际上，任何可以定义的东西（如生成器、协同程序甚至是装饰过的对象）都可以装饰，这意味着装饰器可以堆叠起来。

前面的示例展示了如何链接装饰器。我们先定义类，然后将@dataclass应用于该类——它将该类转换为数据类，充当这些属性的容器。之后，通过@Serialization把逻辑应用到该类上，从而生成一个新类，其中添加了新的serialize()方法。

装饰器另一个好的用法是用于应该用作协同程序的生成器。我们将在第7章中探讨生成器和协同程序的细节，其主要思想是，在向新创建的生成器发送任何数据之前，必须通过调用next()将后者推进到下一个yield语句。这是每个用户都必须记住的手动过程，因此很容易出错。我们可以轻松创建一个装饰器，使其接收生成器作为参数，调用next()，然后返回生成器。

5.1.4　将参数传递给装饰器

至此，我们已经将装饰器看作Python中的一个强大工具。如果我们可以将参数传递给装饰器，使其逻辑更加抽象，那么其功能可能会更加强大。

有几种实现装饰器的方法可以接收参数，但是接下来我们只讨论最常见的方法。第一种方法是将装饰器创建为带有新的间接层的嵌套函数，使装饰器中的所有内容深入一层。第二种方法是为装饰器使用一个类。

通常，第二种方法更倾向于可读性，因为从对象的角度考虑，其要比3个或3个以上使用闭包的嵌套函数更容易。但是，为了完整起见，我们将对这两种方法进行探讨，以便你可以选择使用最适合当前问题的方法。

1．带有嵌套函数的装饰器

粗略地说，装饰器的基本思想是创建一个返回函数的函数（通常称为高阶函数）。在装饰器主体中定义的内部函数将是实际被调用的函数。

现在，如果希望将参数传递给它，就需要另一间接层。第一个函数将接收参数，在该函数中，我们将定义一个新函数（它将是装饰器），而这个新函数又将定义另一个新函数，即装饰过程返回的函数。这意味着我们将至少有3层嵌套函数。

如果你到目前为止还不明白上述内容的含义，也不用担心，待查看下面给出的示例之后，就会明白了。

第一个示例是，装饰器在一些函数上实现重试功能。这是个好主意，只是有个问题：实现不允许指定重试次数，只允许在装饰器中指定一个固定的次数。

现在，我们希望能够指出每个示例有多少次重试，也许甚至可以为这个参数添加一个默认值。为了实现这个功能，我们需要用到另一层嵌套函数——先用于参数，然后用于装饰器本身。

这是因为如下代码：

@retry(arg1, arg2,... )

必须返回装饰器，因为@语法将把计算结果应用到要装饰的对象上。从语义上讲，它可以翻译成如下内容：

<original_function> = retry(arg1, arg2, ....)(<original_function>)

除了所需的重试次数，我们还可以指明希望控制的异常类型。支持新需求的新版本代码可能是这样的：

RETRIES_LIMIT = 3

def with_retry(retries_limit=RETRIES_LIMIT, allowed_exceptions=None):
    allowed_exceptions = allowed_exceptions or (ControlledException,)

    def retry(operation):

        @wraps(operation)
        def wrapped(*args, **kwargs):
            last_raised = None
            for _ in range(retries_limit):
                try:
                    return operation(*args, **kwargs)
                except allowed_exceptions as e:
                    logger.info("retrying %s due to %s", operation, e)
                    last_raised = e
            raise last_raised

        return wrapped

    return retry

下面是这个装饰器如何应用于函数的一些示例，其中显示了它接收的不同选项：

# decorator_parametrized_1.py
@with_retry()
def run_operation(task):
    return task.run()

@with_retry(retries_limit=5)
def run_with_custom_retries_limit(task):
    return task.run()

@with_retry(allowed_exceptions=(AttributeError,))
def run_with_custom_exceptions(task):
    return task.run()

@with_retry(
    retries_limit=4, allowed_exceptions=(ZeropisionError, AttributeError)
)
def run_with_custom_parameters(task):
    return task.run()

2．装饰器对象

前面的示例需要用到3层嵌套函数。首先，这将是一个用于接收我们想要使用的装饰器的参数。在这个函数中，其余的函数是使用这些参数和装饰器逻辑的闭包。

更简洁的实现方法是用一个类定义装饰器。在这种情况下，我们可以在__init__方法中传递参数，然后在名为__call__的魔法方法上实现装饰器的逻辑。

装饰器的代码如下所示：

class WithRetry:

    def __init__(self, retries_limit=RETRIES_LIMIT,
allowed_exceptions=None):
        self.retries_limit = retries_limit
        self.allowed_exceptions = allowed_exceptions or
(ControlledException,)

    def __call__(self, operation):

        @wraps(operation)
        def wrapped(*args, **kwargs):
            last_raised = None

            for _ in range(self.retries_limit):
                try:
                    return operation(*args, **kwargs)
                except self.allowed_exceptions as e:
                    logger.info("retrying %s due to %s", operation, e)
                    last_raised = e
            raise last_raised

        return wrapped

这个装饰器可以像之前的一样应用，就像这样：

@WithRetry(retries_limit=5)
def run_with_custom_retries_limit(task):
    return task.run()

注意Python语法在这里是如何起作用的，这一点很重要。首先，我们创建对象，这样在应用@操作之前，对象已经创建好了，并且其参数传递给它了，用这些参数初始化这个对象，如init方法中定义的那样。在此之后，我们将调用@操作，这样该对象将包装名为run_with_custom_reries_limit的函数，而这意味着它将被传递给call这个魔法方法。

在call这个魔法方法中，我们定义了装饰器的逻辑，就像通常所做的那样——包装了原始函数，返回一个新的函数，其中包含所要的逻辑。

5.1.5　充分利用装饰器

本节介绍一些充分利用装饰器的常见模式。在有些常见的场景中使用装饰器是个非常好的选择。

可用于应用程序的装饰器数不胜数，下面仅列举几个最常见或相关的。

（1）转换参数。更改函数的签名以公开更好的API，同时封装关于如何处理和转换参数的详细信息。

（2）跟踪代码。记录函数及其参数的执行情况。

（3）验证参数。

（4）实现重试操作。

（5）通过把一些（重复的）逻辑移到装饰器中来简化类。

接下来详细讨论前两个应用程序。

1．转换参数

前文提到，装饰器可以用来验证参数（甚至在DbC的概念下强制一些前置条件或后置条件），因此你可能已经了解到，这是一些处理或者操控参数时使用装饰器的常用方法。

特别是，在某些情况下，我们会发现自己反复创建类似的对象，或者应用类似的转换，而我们希望将这些转换抽象掉。大多数时候，我们可以通过简单地用装饰器实现这一点。

2．跟踪代码

在本节中讨论跟踪时，我们将提到一些更通用的内容，这些内容与处理所要监控的函数的执行有关，具体是指：

(1) Actually track the execution of the function (for example, by recording the lines of function execution);

(2) Monitor some indicators of the function (such as CPU usage or memory usage);

(3) Measure the running time of the function;

(4) Log when the function is called, and the parameters passed to it.

We will analyze a simple decorator example in Section 5.2, which records the execution of the function, including the function name and running time.

This article is excerpted from "Writing Clean Python Code"

This book introduces the main practices and principles of Python software engineering, aiming to help readers write code that is easier to maintain and cleaner. code. The book has 10 chapters in total: Chapter 1 introduces the basic knowledge of the Python language and the main tools needed to build a Python development environment; Chapter 2 describes Python style code and introduces the first idiom in Python; Chapter 3 summarizes the principles of good code General features, reviewing general principles in software engineering; Chapter 4 introduces a set of principles for object-oriented software design, namely SOLID principles; Chapter 5 introduces decorators, which are one of the most unique features of Python; Chapter 6 discusses description Descriptors, introducing how to obtain more information from objects through descriptors; Chapters 7 and 8 introduce generators and related content on unit testing and refactoring; Chapter 9 reviews the most common design patterns in Python; Chapter 10 Zhang once again emphasizes that clean code is the basis for achieving good architecture.

This book is suitable for all Python programming enthusiasts, people interested in programming, and other software engineering practitioners who want to learn more about Python.

Related free learning recommendations: python tutorial(Video)

The above is the detailed content of What are decorators in Python? How do decorators work?. For more information, please follow other related articles on the PHP Chinese website!