model_validate is not meant to be used as an instance method, and should never modify the input object.

It seems this is just meant to address the case where you do an invalid model_construct as brought up in #6901, but:

• Using model_construct to create improperly-initialized models is not how it's meant to be used, and is not a workflow we want to accommodate
• As a rule, passing an input to model_validate/validate_python shouldn't modify that input
• This adds some overhead to model_validate/validate_python for everyone to avoid issues caused by invalid model_construct; and given how performant we've made validation through the use of rust, I suspect this overhead is significant for some cases (such as TypeAdapter(int), for example).

As a result, I think this PR is not likely to be merged.

@dmontagu even if I can hear the motivations for performance, I have to admit I find it rather strange that by default an explicit call to the validation method doesn't do anything, even if the model has been modified after it was created in the code. So once the object has been created, there's no way to validate it again unless you explicitly allow it via the model_config attribute... 🤔 When you develop a service and you get the response model instance from a call to an other method or ??? do you have to dig into the code to check that the model has been properly initialized nor have been modified after the creation in a way that it's no more valid since you can't expect that the the call to the validation method done by fastapi when the response is build will effectively validate again the model?

FastAPI will never create an invalid model from data, which is what it is meant to handle.

If you just don’t use model_construct in your code you won’t have this problem.

FastAPI will never create an invalid model from data, which is what it is meant to handle.

If you just don’t use model_construct in your code you won’t have this problem.

@dmontagu Thank you for all your explanations.