What does this tell us about our annotation application in general?

I think it reveals a limitation of our current annotation application. Because paths could be considered as a custom type (i.e. there's no core schema that represents this type, we currently build the validation logic with a customafter validator), we face the limitation of not having access to the annotated metadata as describedhere.

The currentmin/max_length_validator function is not going to scale well in the future if we ever want to add support formin/max_length for another type similar toPath (and that type similarly doesn't have a core schema type for it).

I'll note that while this limitation shows up here with a type without a proper core schema for it, we also face weird behaviors with the following (and unlikePath,int has a core schema type):

defval(v):print('val called')returnvclassModel(BaseModel):a:Annotated[int,AfterValidator(val),Field(gt=0)]Model(a=-1)#> val called#> ValidationError raised

• the after validator is calledbefore thegt validation, which imo is not what should happen.
• as a consequence, thegt constraint isn't represented in theint_schema(), but instead thegreater_than_validator Python fallback validator function is used.

On another note, maybe we should discuss how we validate "concrete" vs "abstract" types. For instance, for paths, we usepathlib.PurePath foros.PathLike annotations, but this is an opinionated choice and users could expectPath to be used instead.

This relates to the behavior ofIterable: we currently validate these by creating aValidationIterator instance, and people complained about it. Maybe we should have a way of customizing which "concrete" implementation should be used for "abstract" types?