Pydantic：数据类与 BaseModel

Question

What are the advantages and disadvantages of using Pydantic's dataclass vs BaseModel? Are there any performance issues or is it easier to Pydantic's dataclass in the other python module?

Answer 1

Your question is answered in Pydantic's documentation , specifically:

Keep in mind that pydantic.dataclasses.dataclass is a drop-in replacement for dataclasses.dataclass with validation, not a replacement for pydantic.BaseModel (with a small difference in how initialization hooks work). There are cases where subclassing pydantic.BaseModel is the better choice.

For more information and discussion see samuelcolvin/pydantic#710 .

The discussion link will give you some of the context you are looking for. In general, Pydantic's BaseModel implementation is not bound to behave the same as Python's dataclass implementation. The example cited in the issue above is one good example:

from pydantic import BaseModel
from pydantic.dataclasses import dataclass
from typing import List

@dataclass
class A:
    x: List[int] = []

# Above definition with a default of `[]` will result in:
#   ValueError: mutable default <class 'list'> for field x is not allowed: use default_factory
# If you resolve this, the output will read as in the comments below.

class B(BaseModel):
    x: List[int] = []

print(A(x=[1, 2]), A(x=[3, 4])) # Output: A(x=[1, 2]) A(x=[3, 4])
print(B(x=[1, 2]), B(x=[3, 4])) # Output: x=[1, 2] x=[3, 4]

If what you want first and foremost is dataclass behavior and then to simply augment it with some Pydantic validation features, the pydantic.dataclasses.dataclass approach may be what you want. Otherwise, BaseModel is probably what you want.

Answer 2

The init Function for BaseModel works differnt than the init for dataclass

@dataclass()
class Foo:
    number: int

class Bar(BaseModel):
    number: int

f = Foo(number = 1.4)
b = Bar(number = 1.4)
print(f)
print(b)

Output:

Foo(number=1.4)
number=1

Answer 3

Another option is to use openapi-json-schema-generator with model generation only. It allows robust validation of many python data types against openapi/json schemas. It

• produces python code which validates payloads against openapi schemas
• produces python classes for any json schema type including no type defined. These are no type defined, null, map, list, number, boolean, string
• can ingest python dict/list/tuple/frozendict/None/bool/int/float/uuid/date/datetime/decimal/bytes/file
• schema instances can also contain bytes + file data
• Uses the json schema test suite to generate many use case tests
• One can see all of those tests here: https://github.com/openapi-json-schema-tools/openapi-json-schema-generator/tree/master/samples/openapi3/client/3_0_3_unit_test/python/test
• It currently tests 24 json schema keywords, CI tests are here
• In one schema, it allows json schema keywords to be combined like oneOf/properties/anyOf/format