1. 14
  1.  

  2. 2

    Hm, one problem I notice is that if we add a third field, like “occupation”, then we can’t guarantee we get back all useful errors. If we place the occ validator in the original block, then we can have name=Drew, age=90, which would fail validate_drew, but we’d never get there as we’d fail the occ validation. What we’d need to do is assemble the validations as a directed graph, topologically sort it, and then walk the sort and run any validations where all the prereqs are valid.

    Unrelated, but an interesting shibboleth here: he defined Valid.apply, not Valid.__call__. With __call__ he could have written a(b) instead of a.apply(b). That tells me he knows Python but isn’t an expert at it, making me wonder if there’s a different approach to declarative validation in Python.

    1. 2

      TIL the word “shibboleth” - I like it!

    2. 1

      If anyone is interested in a declarative validation library for python you might want to check out pydantic. It’s not a direct analog to applicative parsing, but you can use validator functions and get back a list of validation errors. By default, it does throw a ValidationError though so if you want something that doesn’t throw errors then you’ll need to do some wrapping.

      1. 1