i think I would call this Validator -- it's not really an abstract class (it has no abstract properties or methods, and there's actually nothing wrong with using it directly with user-provided params). it's likely that we'd want the final API to look more like our other core APIs and use syntax like @validator to decorate the validation function

prefer validation_fn to be consistent with style throughout codebase

we should check that this is callable

consider min_value/max_value or min_/max_

why the caps

what's implicit about this

no type checking is done so this can raise an unhandled runtime TypeError, e.g. when data is ['a', 'b'] and minim is 3

again, i don't think this is really an abstract class, since it can be directly instantiated and work fine. i *think* what you're trying to get at is that a user might want to implement their own behavior for AbstractResponse.react in the non-exception case, thus the NotImplementedError there?

we should check types in the constructor

my instinct would be to sugar this in the constructor rather than in react, esp if you want users to be able to override react

should probably be a DagsterError

consider ValidationEngine

since this and report_or_fail aren't yet hardened concepts it's helpful to have docstrings making plain their intention & how they interact.

prefer a docstring describing what the user has to implement -- this is unreachable code

it seems like the branch on l. 55 can never be hit?

is this backwards?

would be nice for these intermediate solids to have names

helpful for future readers who lack context on how this closure works to have a note here explaining what value=val and response=resp are doing. it might be clearer if you broke out the solid generation into a separate factory utility

i presume this doesn't actually work (it would have to be value.as_solid()(dat) and then i think you'd see a different error)

hm, interesting that you didn't choose to follow the same pattern here and have AbstractResponse.as_solid. it seems to me that you can *either* blow them both out into solids & construct a composite *or* construct a single validation solid that aggregates the internal logic, but that mixing them as here is unlikely to play nicely

i'm not sure what this is trying to do exactly -- self is probably not what you think it is here

the _ prefix is really intended for unused params -- just call this context. again, i don't think self is what you think.