Skip to content
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

Closed
mahmoud opened this issue May 9, 2018 · 5 comments
Closed

Check() and validate #7

mahmoud opened this issue May 9, 2018 · 5 comments

Comments

@mahmoud
Copy link
Owner

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 mentioned this issue May 9, 2018
@dwt
Copy link

dwt commented May 10, 2018

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

@mcgfeller
Copy link

You might want to check some considerations for Schemas I've writted up in https://ict.swisscom.ch/2017/12/python-schema/. There are many solutions, none fits all purposes and most of them leave lot to be improved.

@jcollado
Copy link

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.

@mahmoud
Copy link
Owner Author

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 :)

@mahmoud
Copy link
Owner Author

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 as completed Jul 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants