Same needs to be done for DCs/TDs

It's a bit annoying because I don't have access to any input inside the default_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 either Option<PyObject> or a new singleton sentinel value, but the rtype is already complex enough 🤔

Actually, the current behavior is a bit weird:

class Model(BaseModel):
 a: int
 b: int
Model(b="fails")
"""
pydantic_core._pydantic_core.ValidationError: 2 validation errors for Model
a
 Field required [type=missing, input_value={'b': 'fails'}, input_type=dict]
 For further information visit https://errors.pydantic.dev/2.11/v/missing
b
 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
"""

For b, a value was provided and is used as input_value. For a, no value is provided and pydantic-core uses the whole input dict as input_value (on L214, input is the provided dict):

So perhaps we could just use PydanticUndefined 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 for a should not include input_value or input_type at all? Or maybe they should be PydanticUndefined 🤔

maybe we could special-case PydanticUndefined 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 of PydanticUndefined 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:

class Model(BaseModel):
 a: int | str

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

Edit: Actually it might be wrong if we have:

class Model1(BaseModel):
 a: int
class Model2(BaseModel): ...
class Model(BaseModel):
 m: Model1 | Model2

if validation fails for Model1.a, it will mutate the state (if it is the same state than when validating Model).

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 for a should not include input_value or input_type at all? Or maybe they should be PydanticUndefined 🤔

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

Field required [type=missing]

?