-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Support compare_as callable at field #10834
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
base: main
Are you sure you want to change the base?
Conversation
CodSpeed Performance ReportMerging #10834 will not alter performanceComparing Summary
|
Coverage reportClick to see where and how coverage changed
This report was generated by python-coverage-comment-action |
please review |
Thanks for the PR. Looks like there are a couple of solutions available on this front, including this one, plus:
Sorry for our review delays here. I've pinged @davidhewitt to see what he thinks regarding the best way forward here. We're eager to get a fix for this / related issues into v2.11! |
Nice! Yeah I openned add default comparison, this is a generalization. In that PR the callable was used only to compare default values, which is done in Rust. The |
Cool. I think we want to move forward with an approach similar to this one. We're pushing out |
Change Summary
This PR adds
compare_as
callable in theField
class to add custom comparison. The classical example in the numpy ndarray, see #7307. Note thatattrs
defines a similareq
callable (see the docs)and the pydantic implementation looks like
Note that I intentionally added a
default = np.array([1,2,3])
to illustrate the example whereexclude_default = True
in the serialization, this callable can be forwarded to the Rust side. See this discussionRelated issue number
#7307
#pydantic/pydantic-core#1114
Checklist
Selected Reviewer: @sydney-runkle