create free standing functions to match model methods

[samuelcolvin]

• a new module with all the methods - what the hell do we call this module?
• call from BaseModel methods
• call from Validator methods V2: The validate general method #4669
• add BareModel
• remove the model_ prefix from the free standing functions
• extra functions we don't want to put on a model, like dump_json_bytes

Incomplete list of functions:

• validate(type[T], data: any) -> T
• validate_json(type[T], data: str | bytes) -> T
• construct(type[T], data) -> T
• dump -> any
• dump_json -> str
• dump_json_bytes -> bytes
• json_schema -> dict
• json_schema_json -> bytes

These should work on models, BareModel, dataclasses, and instrances of Validator (#4669).

Name ideas for this module: standalone, methods (technically they're the opposite), free???

[realDragonium]

Perhaps we should splits it up in a multiple modules which can have more specific names? Like 'serialization' and 'validation'?

imo something like, would have more clarity for me

from .model import construct
from .serialization import dump, dump_json, validate
from .validation import validate, validate_json

Compared to something like this

from .util import construct, dump, dump_json_bytes, validate, validate_json

But if you're not looking to split it up, the common theme i notice is model/dataclass. Serialization, creation and validation of such thing... so instead of having model_ as prefix of the method, we can just call the module model?

[dmontagu]

I will say — I don't think method/methods would be crazy if they really were just unbound "methods" (i.e., functions that always expect to receive an instance of a BaseModel subclass as the first argument).

I like model or methods less as the module name if they are meant to work equivalently on arbitrary values/types though, which I suspect they are? (E.g., dump_json([1, 2, MyModel(x=1)])).

I think dataclasses dumps its "free-standing" functions in the top-level namespace (e.g., dataclasses.asdict, dataclasses.fields, etc.) — we could just put the pydantic equivalents as top-level exports (i.e., pydantic.validate, pydantic.dump, etc.)

[samuelcolvin]

I think methods makes sense, even if technically it's a misnomer.

I think all functions should either take a type or an instance of model or dataclass.

[realDragonium]

I think all functions should either take a type or an instance of model or dataclass.

My concern with naming it methods is: would it be obvious enough for people that only those types of functions should be placed in there?

[samuelcolvin]

would it be obvious enough for people

yes, because we would document that.

I think methods is satisfactory unless we can think of something better.

Need to also have:

• fields_set(m): m.__fields_set__ could be a property, we should also add a @property to BaseModel - model_fields_set(self): return self.__fields_set__
• rebuild() - akin to .model_rebuild()

[Kludex]

Is this still wanted? @samuelcolvin

[samuelcolvin]

I think there's a chance we might still want this, especially if we end up with FastModel which internally stores data in rust types — there would be an even stronger reason to use a pydantic (fast) model over a dataclass, and people would reasonably want a variant with an unpolluted namespace.