Inspired by some of the wonderful ideas in schema and flatland, many of which
I outright stole.

The goal is to make validation faster than either, while keeping the very
pythonic and minimal style of schema , at the expense of more advanced
features.

Current status is: used in production code, but only in one place that I know
of.

I have not optimized much, but for the kind of schemas I need (specifically: to
validate JSON that has been loaded into python structures as part of a REST
API,) I have some anecdotal evidence that it’s around ten times faster than
both schema and flatland. (Again, that is mostly because it does way less.)

The schemas understood by val are very similar to the ones in schema , but not
100% compatible.

Dictionaries

Dictionaries will validate dictionaries all of whose key value pairs are
validated by at least one of the key value pairs in the schema, and that are
not missing any of the keys specified (unless they are specified as
Optional()):

To get nicer error messages, use functions rather than lambdas (if the function
has a doc string it will be used in the error message, otherwise the name of
the funtion will):

>>>defless_than_ten(n):..."""Must be less than 10."""...returnn<10>>>schema=Schema(less_than_ten)>>>schema.validates(9)True>>>schema.validate(10)Traceback(mostrecentcalllast):...val.NotValid:10invalidatedby'Must be less than 10.'

Convert()

Convert(callable) will call the callable on the value being validated,
and substitute the result of that call for the original value in the
validated structure. TypeErrors or ValueErrors in the call will result in a
NotValid exception. This or supplying Default Values are the only ways to
modify the data during validation. For that reason it should be used sparingly.

Convert is useful to convert between representations (for instance from
timestamps to datetime objects, or uuid string representations to uuid objects,
etc.):

Ordered()

Ordered([element1, element2, element3]) will validate a list with
exactly 3 elements, each of which must be validated by the corresponding
element in the schema. If order and number of elements do not matter, just
use Lists:

FAQ

How do I validate only some of the keys in a dictionary?

Often when validating input there will be values present that your code doesn’t
act upon, and doesn’t care about the presence or absence of. You can make your
schema similarly indifferent by adding str: object (assuming the keys in
the dictionary are all strings, like they are when your data comes from JSON.
If even the type of the keys is variable, you can use object: object.) This
will match and validate any keys in the dictionary that you didn’t explicitly
specify.

Additional Validators

Sometimes it is useful to do validation that depends on multiple parts of the
data at once. For this purpose, Schemas can be initialized with additional
validators.

>>>defmaximum_total(value):..."""The total sum must not exceed 500."""...returnsum(value.values())<=500>>>schema=Schema({str:int},additional_validators=(maximum_total,))>>>schema.validates({'foo':12,'bar':400})True>>>schema.validate({'foo':250,'bar':251})Traceback(mostrecentcalllast):...val.NotValid:...invalidatedby'The total sum must not exceed 500.'

Serializing Schemas

When your application receives JSON from clients, it can be useful to define
explicit schemas that those clients have to abide by. Pointing to source code
isn’t an especially great way to communicate to other developers what is or
isn’t considered valid JSON by your application, especially if they aren’t
developing in Python. For this purpose, teleport, a lightweight JSON format to
describe schemas, is better suited.

A subset of valid val schemas is serializable/exportable to teleport.
Note that things like default values and additional validators will be lost
when serializing to teleport, because it has no way to express them.

Combining doctests with this serialization provides a way to specify what your
application considers valid, and verify in your tests that you didn’t
unintentionally break clients’ assumptions.