gdementen
commented
10 months ago FWIW, here are the pro and cons of pydantic (v2) vs our own solution:
Pros:
- more standard
- probably easier to evolve more features (range checking and stuff like that).
- maybe there is hope of having someday the axes validated statically (by PyCharm/mypy/...) in addition to at runtime
- probably faster (due to v2 using a rust runtime), but that needs to be checked as v1 is much slower than our custom solution. Speed is irrelevant (fast enough) either way in our typical uses cases though.
Cons:
- For our current required feature set, using Pydantic is more complex than an homegrown solution AFAICT
- Using an external solution involves more risk of having to adapt again in the future
- One more dependency to track
I would say that, in the end, if we only ever want to support the current feature-set with only runtime checking of axes, a custom solution would be less (maintenance) work.
Pydantic2 has been released in june 2023 and it is a massive change compared to v1. There is even a whole migration guide at: https://docs.pydantic.dev/2.0/migration/
Needless to say, larray is not compatible with it. We should either rewrite Checked* using v2, or stop using Pydantic at all (I have some proof of concept code doing this somewhere).
PS: CI is not failing on this (yet) because anaconda packages for Pydantic are still at v1. But I noticed the error via readthedocs where pydantic is installed via pip instead.