Python 为什么在 SQLAlchemy 或 Pydantic 等流行包中的 __init__ 之外定义属性

直接在类命名空间中定义类的属性是完全可以接受的，并且对于您提到的包本身并不特殊.由于类命名空间(以及其他内容)本质上是该类实例的蓝图，因此在那里定义属性实际上可能是有用的，例如，当您想要以一致的方式在单个位置为所有公共属性提供类型注释时.

还要考虑公共属性不一定需要由类的构造函数中的参数反映.例如，这是完全合理的:

class Foo:
    a: list[int]
    b: str

    def __init__(self, b: str) -> None:
        self.a = []
        self.b = b

换句话说，仅仅因为某些东西是公共属性，并不意味着它必须在初始化时由用户提供.更不用说受保护/私有属性了.

Pydtic的特殊之处(以您的例子为例)是BaseModel的元类以及类本身对类命名空间中定义的属性进行了大量的魔术处理.PYDANIC将模型的典型属性称为"字段"，并且在初始化过程中可以根据在类名称空间中定义的那些字段执行特殊判断.例如，构造函数必须接收与您定义的非可选字段相对应的关键字参数.

from pydantic import BaseModel


class MyModel(BaseModel):
    field_a: str
    field_b: int = 1


obj = MyModel(
    field_a="spam",  # required
    field_b=2,       # optional
    field_c=3.14,    # unexpected/ignored
)

如果我在构造MyModel实例的过程中省略了field_a，则会引发错误.同样，如果我试图通过field_b="eggs"，就会出现错误.

因此，您不编写自己的__init__方法的事实是feature个平凡的东西提供给您.您只需定义字段，相应的构造函数就已经"神奇"地为您准备好了.

至于你提到的缺点，你不会得到任何自动建议，默认情况下，所有IDE都是如此.静态类型判断器不能理解动态构造函数并简单地推断需要什么参数.目前，这是通过扩展解决的，如mypy plugin和PyCharm plugin.也许很快就会成为PEP 681年的@dataclass_transform名室内设计师 将对类似的包进行标准化，从而提高静态类型判断器的支持.

同样值得注意的是，即使标准库的dataclasses也只能在类型判断器中通过special extensions工作.

对于您的另一个问题，显然对此类类的方法有一些影响(通过设计)，尽管细节并不总是显而易见的.当然，您不应该简单地编写您自己的__init__方法，而不小心在其中正确地调用超类‘__init__.此外，@property-setters目前有don't work as you would expect it个(尽管在Pydtic模型上使用属性是否有意义还有待商榷).

总而言之，这种方法不仅是not个糟糕的做法，它是一个减少样板代码的好主意，而且现在它非常普遍，这一事实证明了非常流行的和成熟的包(如前面提到的Pydtic，以及例如SQLAlChemy、Django和其他)在一定程度上使用了这种模式.