Add string schema inputs to validator_for

[bollwyvl]

Thanks for jsonschema-rs!

To align with the first chunk of Python Usage, this adds str as an acceptable schema value to validator_for as well as the also-useful validator_cls_for.

I tried these interactively with the current latest PyPI releases. The validate function does not accept a string, which might be nice for consistency.

As for avoiding stdlib json.parse (and even string decoding) in a few more places: I don't have the rust chops to dig much further, but it would be very nice if:

• the above validator builders also accepted bytes, and/or potentially readable file-like objects
• if validators were able to "parse, not validate" incoming JSON str/bytes
  • from a typing syntax perspective, it might be nice if these supported an as_type to refine the Any return value

Thanks again!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.49%. Comparing base (bf78920) to head (58ed2dc).
⚠️ Report is 5 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1074   +/-   ##
=======================================
  Coverage   94.49%   94.49%           
=======================================
  Files          81       81           
  Lines       22610    22610           
=======================================
  Hits        21366    21366           
  Misses       1244     1244           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Stranger6667]

Thanks @bollwyvl !

validator_cls_for does not currently support parsing schemas from string - I am going to merge this PR and will adjust it and will check other parts of the public API regarding this matter (and the corresponding parts of Ruby bindings too).

the above validator builders also accepted bytes, and/or potentially readable file-like objects

Yes, it would add a few branches, but I think it is fine for convenience.

if validators were able to "parse, not validate" incoming JSON str/bytes
from a typing syntax perspective, it might be nice if these supported an as_type to refine the Any return value

could you, please, elaborate on this? how such a workflow would look like?

[codspeed-hq]

Merging this PR will not alter performance

✅ 68 untouched benchmarks

---

_{Comparing bollwyvl:patch-1 (58ed2dc) with master (bf78920)}

[bollwyvl]

Thanks for the review!

Sorry about the commit message fails. Please feel free to rebuild this in whatever ways needed!

how such a workflow would look like?

From the rust side, no idea! 🤷

From the python side, it could look like how msgpec's various decode functions work, but unsure about strict vs lax behavior.

Thinking about it as a method on a validator:

from jsonschema_rs import validator_for, ValidationError

validator = validator_for(b`{"type": "number", "format": "integer"}`, as_type=int)

good_instance = validator.loads(b"1")

try:
    bad_instance = validator.loads(b"a")
except ValidationError:
    ...

Even if the above was purely "cosmetic," just to inform a PEP-484 type checker, it would work with techniques for getting hints from schema, such as jsonschem-gentypes, which could be checked at test time with e.g. beartype/typeguard.

[Stranger6667]

Thats cool!

When you mentioned "parse, not validate" I was thinking about parsing incoming bytes with json schema rules, but it would be a completely different compilation flow where the biggest issue would be random access for applicators ($ref specifically) and I would assume that overhead would be quite significant there with questionable gains in terms of overall performance (the output type will be serde_json::Value anyway on the rust side)

But purely Python side looks interesting, I'll think about it