-
Notifications
You must be signed in to change notification settings - Fork 239
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
introduce "bound validators" for int, str, float #675
Conversation
CodSpeed Performance ReportMerging #675 will improve performances by 55.52%Comparing Summary
Benchmarks breakdown
|
@davidhewitt I think the extra is probably the only source of setting the strictness; the only way I'm aware of doing runtime manipulation of strictness from pydantic is the I wouldn't say I'm confident in the above though, maybe a question for @samuelcolvin or @adriangb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks great, feel free to merge or add more usage here if you like.
yes, your guesses about |
c3dce30
to
e4d9990
Compare
e4d9990
to
8e60f2a
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #675 +/- ##
==========================================
+ Coverage 93.63% 93.73% +0.10%
==========================================
Files 99 99
Lines 13895 13877 -18
Branches 25 25
==========================================
- Hits 13010 13008 -2
+ Misses 879 863 -16
Partials 6 6
... and 29 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
I would love to come back to this idea one day but I think first will focus on more bugfixes / the PyO3 changes and see where performance sits after that. |
This attempts to optimize validators for collections (currently just
list
anddict
in this draft, could be extended to all of them) by making an extra "binding" step before validating a collection. The bound validator has the final strictness determined form both schema and extra.The idea is that this should help avoid branches for laxness / strictness on each step of the collection validation. Seems to offer a modest speedup.
This design may fall apart if there's more ways to set strictness than by the schema and the extra (e.g. at runtime, maybe some validator chooses its strictness based on a function call).
Pushed this as a draft now because it would be interesting to gather feedback before pushing a load more additional complexity.