Same needs to be done for DCs/TDs

It's a bit annoying because I don't have access to any input inside thedefault_value method.@davidhewitt any idea how I could workaround this in a clean way? I could wrap up the return type in an enum of eitherOption<PyObject> or a new singleton sentinel value, but the rtype is already complex enough 🤔

Actually, the current behavior is a bit weird:

classModel(BaseModel):a:intb:intModel(b="fails")"""pydantic_core._pydantic_core.ValidationError: 2 validation errors for Modela  Field required [type=missing, input_value={'b': 'fails'}, input_type=dict]    For further information visit https://errors.pydantic.dev/2.11/v/missingb  Input should be a valid integer, unable to parse string as an integer [type=int_parsing, input_value='fails', input_type=str]    For further information visit https://errors.pydantic.dev/2.11/v/int_parsing"""

Forb, a value was provided and is used asinput_value. Fora, no value is provided and pydantic-core uses the whole input dict asinput_value (on L214,input is the provided dict):

So perhaps we could just usePydanticUndefined as an input value here, and then in the with_default validator, I can return:

Err(ValError::new(ErrorTypeDefaults::DefaultFactoryNotCalled,&self.undefined))

Hmm interesting, I wonder if the error fora should not includeinput_value orinput_type at all? Or maybe they should bePydanticUndefined 🤔

maybe we could special-casePydanticUndefined in errors, so it would just show

Field required [type=missing]

?

I'll see if this can be done without too much special casing, I agree it would be better.

Why do we need to track this on the state? Should we adjust the algorithm to just never call.default_value if there's any errors?

(We could go further and rearrange things a bit so that all default values only get filled in after the whole input is processed, there is some overlap with#1620 🤔)

Why do we need to track this on the state? Should we adjust the algorithm to just never call .default_value if there's any errors?

It's only relevant for default factories taking the data argument, so if you just have a "static" default it shouldn't matter. And because the logic to call the default value is nested under the current field validator, I can't really "influence" the logic from the model field.

This state approach doesn't look right, but I couldn't find a better way to do so 🤔

(We could go further and rearrange things a bit so that all default values only get filled in after the whole input is processed, there is some overlap with#1620 🤔)

Would this allow using other field values independently from the field order?

Ah, I see. I missed the default factories guarantee field order; this makes a lot of sense.

Because of the existence ofPydanticUndefined as a way to ask for defaults, I think my original proposal actually doesn't make sense. 🤔

... but I do worry about when this flag is reset. Currently once you set it it's true for the rest of the validation. This seems problematic in unions, for example.

Indeed this is one of the reasons it doesn't look right; however, for unions I think it should be alright, as there's a boundary in the validation error.

The error we are handling here is the validation error of the field. If this field is defined like:

classModel(BaseModel):a:int|str

And a validation error happens onint, the field validator will try validating againststr. At this point, we don't know what happened, and we will only get a val error if validation againststr failed as well.

Edit: Actually it might be wrong if we have:

classModel1(BaseModel):a:intclassModel2(BaseModel): ...classModel(BaseModel):m:Model1|Model2

if validation fails forModel1.a, it will mutate the state (if it is the same state than when validatingModel).

Now the question is: are unions the only concern? If so, we can make sure we somehow reset this state value on union validation, but there might be other concerns apart from unions :/

Hmm interesting, I wonder if the error fora should not includeinput_value orinput_type at all? Or maybe they should bePydanticUndefined 🤔

maybe we could special-casePydanticUndefined in errors, so it would just show

Field required [type=missing]

?