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 custom after validator), we face the limitation of not having access to the annotated metadata as described here.

The current min/max_length_validator function is not going to scale well in the future if we ever want to add support for min/max_length for another type similar to Path (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 unlike Path, int has a core schema type):

def val(v):
    print('val called')
    return v

class Model(BaseModel):
    a: Annotated[int, AfterValidator(val), Field(gt=0)]

Model(a=-1)
#> val called
#> ValidationError raised

• the after validator is called before the gt validation, which imo is not what should happen.
• as a consequence, the gt constraint isn't represented in the int_schema(), but instead the greater_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 use pathlib.PurePath for os.PathLike annotations, but this is an opinionated choice and users could expect Path to be used instead.

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