added koda_validate.signature and all its contents.
validate_signature is the main chunk of code
other public classes and functions are specified as well
implemented resolve_signature_typehint_default to provide custom typehint resolution
codified Coercer, and build a decorator for ergonomics. There were a lot of variations for how to define this that I considered.
renamed _ExactTypeValidator to _ToTupleStandardValidator
_ToTupleStandardValidator allows for custom coercion
deleted _CoercingValidator and rolled it into _ToTupleStandardValidator
I didn't include any of the public members of .signature in the root init.all object because I think this is fundamentally non-core. (The same approach is taken with .serialization).
I updated a lot of documentation! But still more on the way in this PR (it's a big PR, so review can start before that's done).
This PR is so large because some validators coerced by without any means of changing their behavior -- this is a problem for function signatures because presumably you don't want to pass an integer for a Decimal argument and have that implicitly coerced into a decimal. After the coercion API additions, resolve_signature_typehint_default now specifies how coercion (or lack thereof) is configured by default for function signature validation.
How to test
Most expected use cases are tested. It would be useful if there were any use cases I haven't thought of here that could be probed.
Issue or goal of PR:
closes #11
What I did
koda_validate.signatureand all its contents.validate_signatureis the main chunk of coderesolve_signature_typehint_defaultto provide custom typehint resolutionCoercer, and build a decorator for ergonomics. There were a lot of variations for how to define this that I considered._ExactTypeValidatorto_ToTupleStandardValidator_ToTupleStandardValidatorallows for custom coercion_CoercingValidatorand rolled it into_ToTupleStandardValidatorI didn't include any of the public members of .signature in the root init.all object because I think this is fundamentally non-core. (The same approach is taken with .serialization).
I updated a lot of documentation! But still more on the way in this PR (it's a big PR, so review can start before that's done).
This PR is so large because some validators coerced by without any means of changing their behavior -- this is a problem for function signatures because presumably you don't want to pass an integer for a
Decimalargument and have that implicitly coerced into a decimal. After the coercion API additions,resolve_signature_typehint_defaultnow specifies how coercion (or lack thereof) is configured by default for function signature validation.How to test
Most expected use cases are tested. It would be useful if there were any use cases I haven't thought of here that could be probed.
Documentation
Check one: