New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check() and validate #7

mahmoud opened this Issue May 9, 2018 · 5 comments


None yet
4 participants

mahmoud commented May 9, 2018

While this wasn't on my mind when I first started out, it's been pointed out to me that glom may also benefit from a validation story.

Some preliminary design work suggests the following would work well:

  • Create a Check() specifier type
  • Support type=..., value=..., and maybe other kwargs.
  • Add an action kwarg to determine what to do if the Check fails the condition ('omit', 'raise', other?)
  • Explore having the spec work like Inspect, where it can wrap a spec or appear on it's own (probably after the spec it's supposed to check)
  • Extend the recursion API to pass through a validation context of some sort so that multiple errors can be registered, instead of just raising immediately (maybe a top-level glom() kwarg controlling this)

This is great for an assert-like functionality here and there, but for heavily Checked specs, we may want to have a convenience construct of some sort.

@mahmoud mahmoud referenced this issue May 9, 2018


Extension API #9


This comment has been minimized.

dwt commented May 10, 2018

I would love if this could serialize to json schema to allow driving libraries like json-editor


This comment has been minimized.

mcgfeller commented May 11, 2018

You might want to check some considerations for Schemas I've writted up in There are many solutions, none fits all purposes and most of them leave lot to be improved.


This comment has been minimized.

jcollado commented May 17, 2018

One thing I've been frustrated with validation libraries is the ability to set custom error messages (mainly for backwards compatibility reasons). Some provide this kind of functionality, but once the schema becomes more complex (for example with nested or with recursive data) then they don't have the desired flexibility. If this can be provided by glom, then that would be great.


This comment has been minimized.


mahmoud commented Jul 5, 2018

@mcgfeller Thanks for the link to the overview document! The related update from us is that we're designing some new interface definitions and still discussing whether to push these down into glom (possibly using the new extension API merged in #9 which is pending launch) or to simply build something that complements glom.

@dwt Per the comment above, Kurt and I are still floating how to expose the limited dialect of glomspecs that also fit into json schema. Definitely an area of interest :)

@jcollado I'm definitely open to this idea, and I created #42 to discuss it further :)


This comment has been minimized.


mahmoud commented Jul 5, 2018

Beyond the replies above, I think #25 being merged closes out this first generation issue :) Thanks all!

@mahmoud mahmoud closed this Jul 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment