Open dmontagu opened 1 year ago
In particular, I think this will be handy for doing strict-mode validation of data that didn't have its origin in python (e.g., data loaded from a
.yml
file or some other serialization format into python objects).
Yup - and also sometimes the way an application/library is structured just means that parsing happens earlier.
Is this something you all would take a PR for? Would it just be a new keyword param called mode
?
On reflection for this, I would like to suggest that instead of "JSON mode" we call this "raw mode", i.e. mode='raw'
, because it only takes a limited set of "raw" datatypes. Functionally it would work like JSON parsing currently does, I guess.
Not easy to implement, but I agree would be nice.
So one way I would try to approach this is to say that a set of Python types has a correspondence to JSON-equivalent values cannot be converted:
And under strict/raw, if a runtime type is in the list, see if the current validator expects a type that has an appropriate corresponding type in the list. If one exists, then no coercion may take place before a validator runs; otherwise non-strict coercions can take place.
I know this glosses over a lot of details of how validators actually work (e.g. string validators that expect a precise data format).
Does that match your intuition?
On reflection for this, I would like to suggest that instead of "JSON mode" we call this "raw mode", i.e.
mode='raw'
, because it only takes a limited set of "raw" datatypes
For what it's worth, the current behavior really does assume something JSON-y as an input format.
Copying from slack:
In particular, I think this will be handy for doing strict-mode validation of data that didn't have its origin in python (e.g., data loaded from a
.yml
file or some other serialization format into python objects).Selected Assignee: @davidhewitt