更轻松地使用类的自定义命名空间

目前，要为类命名空间使用不同的类型（例如 `collections.OrderedDict`），或使用预填充的命名空间，需要编写和使用自定义元类。使用本 PEP，使用自定义命名空间变得像在类头中指定适当的工厂函数一样简单。

更轻松地继承定义时行为

理解 Python 的元类需要深入理解类型系统和类构造过程。由于需要在你的脑海中清晰地区分多个活动部件（代码、元类提示、实际元类、类对象、类对象的实例），这被认为是具有挑战性的。即使你了解规则，如果你不小心，也很容易犯错。本 PEP 的早期版本实际上包含了这样一个错误：它将实际上是“type 的实例”的约束声明为“type 的子类”。

理解提议的隐式类装饰器钩子只需要理解装饰器和普通方法继承，这并不是一项令人生畏的任务。新的钩子提供了一条更渐进的路径来理解类定义过程中涉及的所有阶段。

减少元类冲突的可能性

使库作者不愿使用元类（即使它们适用）的主要问题之一是元类冲突的风险。每当类定义所需的父类使用两个不相关的元类时，就会发生这种情况。这种风险也使得在之前没有元类的类中添加元类变得非常困难。

相比之下，向现有类型添加 `__autodecorate__` 方法带来的风险与添加 `__init__` 方法类似：从技术上讲，存在破坏实现不当的子类的风险，但当发生这种情况时，它被认为是子类中的错误，而不是库作者违反向后兼容性保证。事实上，由于 `__autodecorate__` 的签名受限，在这种情况下，风险实际上甚至低于 `__init__` 的情况。

与 PEP 3135 无缝集成

与作为元类一部分运行的代码不同，作为新钩子一部分运行的代码将能够自由地调用依赖于 `PEP 3135 <../pep-3135/>` 引入的隐式 `__class__` 引用（包括使用 `super()` 的零参数形式的方法）的类方法。

替换 __metaclass__ 的许多动态设置用例

对于不涉及完全替换已定义类的用例，现在可以使用 Python 2 代码动态设置 `__autodecorate__` 而不是动态设置 `__metaclass__`。对于更高级的用例，仍然需要引入显式元类（可能作为必需的基类提供）以支持 Python 3。

确定正在装饰的类是否为基类

在 `__autodecorate__` 方法的主体中，与任何其他类方法一样，`__class__` 将绑定到声明该方法的类，而传入的值可能是子类。

这使得在必要时跳过处理基类变得相对简单。

class Example:
    def __autodecorate__(cls):
        cls = super().__autodecorate__()
        # Don't process the base class
        if cls is __class__:
            return
        # Process subclasses here
        ...

用不同类型的对象替换类

作为隐式装饰器，`__autodecorate__` 能够相对轻松地用其他类型的对象替换已定义的类。从技术上讲，自定义元类甚至 `__new__` 方法已经可以隐式地做到这一点，但装饰器模型使此类代码更容易理解和实现。

class BuildDict:
    def __autodecorate__(cls):
        cls = super().__autodecorate__()
        # Don't process the base class
        if cls is __class__:
            return
        # Convert subclasses to ordinary dictionaries
        return cls.__dict__.copy()

目前尚不清楚为什么有人会基于继承隐式地执行此操作，而不是仅仅使用显式装饰器，但这种可能性似乎值得注意。

namespace 概念是否值得额外的复杂性？

与新的 `__autodecorate__` 钩子不同，提议的 `namespace` 关键字参数不会被子类自动继承。鉴于本提案目前的写法，获得在子类中始终一致使用的特殊命名空间的唯一方法仍然是编写具有合适的 `__prepare__` 实现的自定义元类。

更改自定义命名空间工厂以使其也继承将大大增加本提案的复杂性，并引入与使用自定义元类时出现的一些相同的潜在基类冲突问题。

Eric Snow 提出了一个 单独的提案，建议将类体的执行命名空间默认设置为有序字典，并将类属性定义顺序作为属性（例如 `__definition_order__`）捕获到类对象上。

Eric 的建议方法可能是 type 的新默认行为的更好选择，它与提议的 `__autodecorate__` 钩子很好地结合，将更复杂的可配置命名空间工厂的想法留给像下面所示的自定义元类。

保持顺序的类

class OrderedClass(namespace=collections.OrderedDict):
    a = 1
    b = 2
    c = 3

预填充的命名空间

seed_data = dict(a=1, b=2, c=3)
class PrepopulatedClass(namespace=seed_data.copy):
    pass

克隆原型类

class NewClass(namespace=Prototype.__dict__.copy):
    pass

扩展类

from collections import MutableMapping

# The MutableMapping + dict combination should give something that
# generally behaves correctly as a mapping, while still being accepted
# as a class namespace
class ClassNamespace(MutableMapping, dict):
    def __init__(self, cls):
        self._cls = cls
    def __len__(self):
        return len(dir(self._cls))
    def __iter__(self):
        for attr in dir(self._cls):
            yield attr
    def __contains__(self, attr):
        return hasattr(self._cls, attr)
    def __getitem__(self, attr):
        return getattr(self._cls, attr)
    def __setitem__(self, attr, value):
        setattr(self._cls, attr, value)
    def __delitem__(self, attr):
        delattr(self._cls, attr)

def extend(cls):
    return lambda: ClassNamespace(cls)

class Example:
    pass

class ExtendedExample(namespace=extend(Example)):
    a = 1
    b = 2
    c = 3

>>> Example.a, Example.b, Example.c
(1, 2, 3)

从 type.__init__ 调用 __autodecorate__

从 `type.__init__` 自动调用新钩子可以实现本 PEP 的大部分目标。但是，使用这种方法意味着 `__autodecorate__` 实现将无法调用任何依赖于 `__class__` 引用（或使用 `super()` 的零参数形式）的方法，并且本身也无法使用这些功能。

当前的设计确保隐式装饰器钩子能够执行显式装饰器可以执行的任何操作，方法是在初始类创建完成后运行它。

调用自动装饰钩子 __init_class__

PEP 的早期版本使用名称 `__init_class__` 作为新钩子的名称。这个名称有三个重要的问题。

• 很难记住正确的拼写是 `__init_class__` 还是 `__class_init__`。
• 名称中使用“init”表明签名应该与 `type.__init__` 的签名匹配，但事实并非如此。
• 名称中使用“init”表明该方法将在类对象创建过程中运行，但事实并非如此。

选择新的名称 `__autodecorate__` 是为了清楚地表明，新的初始化钩子最有用地被认为是隐式调用的类装饰器，而不是像 `__init__` 方法。

要求在 __autodecorate__ 上使用显式装饰器

最初，本 PEP 要求在 `__autodecorate__` 装饰器上显式使用 `@classmethod`。它被设为隐式，因为没有合理的解释可以省略它，并且无论如何都需要检测这种情况以提供有用的错误消息。

在注意到定义 `__prepare__` 并忘记 `@classmethod` 方法装饰器的用户体验是完全难以理解的之后，这一决定得到了加强（特别是由于 `PEP 3115 <../pep-3115/>` 将其记录为普通方法，并且当前文档没有明确说明任何一方）。

使 __autodecorate__ 隐式静态，如 __new__

虽然它接受要实例化的类作为第一个参数，但 `__new__` 实际上被隐式地视为静态方法而不是类方法。这使得它可以很容易地从其定义类中提取并直接在子类上调用，而不是与它从中检索的类对象耦合。

这种行为最初似乎对新的 `__autodecorate__` 钩子可能有用，因为它允许 `__autodecorate__` 方法很容易地用作其他类的显式装饰器。

但是，这种明显的支持将是一种错觉，因为它仅在子类上调用时才能正常工作，在这种情况下，该方法可以同样容易地从子类中检索并以这种方式调用。与 `__new__` 不同，在继承链的不同点更改方法签名没有任何问题。

直接传入命名空间而不是工厂函数

在某一时刻，本 PEP 建议将类命名空间直接作为关键字参数传递，而不是传递工厂函数。但是，这鼓励了一种不受支持的行为（即，将相同的命名空间传递给多个类，或保留对用作类命名空间的映射的直接写入访问权限），因此 API 切换到工厂函数版本。