@hynek
This is not a bug report or an issue, but rather a question of whether support for more intelligent / composable validators would be accepted?
In the latest project where I have a few dozen different classes in the schema, I made a bunch of wrappers around validators (e.g. so you don't have to type attr.validators.instance_of every time, and a few other simplifications), I'll provide a few lines of sample code below:
fields_start = typed(non_negative(int), default=0)
checks = typed(list_of(Check), default=attr.Factory(list))
values = typed(non_empty(dict_of(non_empty(str), int)))
Here typed is a very lightweight wrapper around attr.ib. All of the validators here are fully composable, plus any type-like objects found where a validator is expected are automatically converted to instance_of (why else would you pass a type object to validator argument?). Would you be interested in extending validators in this way? If so, I could try and pack some of this up into a PR 😸
@hynek
This is not a bug report or an issue, but rather a question of whether support for more intelligent / composable validators would be accepted?
In the latest project where I have a few dozen different classes in the schema, I made a bunch of wrappers around validators (e.g. so you don't have to type
attr.validators.instance_ofevery time, and a few other simplifications), I'll provide a few lines of sample code below:Here
typedis a very lightweight wrapper aroundattr.ib. All of the validators here are fully composable, plus any type-like objects found where a validator is expected are automatically converted toinstance_of(why else would you pass a type object tovalidatorargument?). Would you be interested in extending validators in this way? If so, I could try and pack some of this up into a PR 😸