pydantic-core VS typedload

Funny that you ask... https://github.com/pydantic/pydantic-core Unfortunately it seems that the functionality you ask for is not (yet) part of this ...

I encourage you to checkout the official benchmarks for more realistic and detailed examples, and, as always, YMMV.

> to also be constrained by a separate set of data types which are legal in rust.

This isn't really how writing rust/python iterop works. You tend to have opaque handles you call python methods on. Here's a decent example I found skimming the code.

https://github.com/pydantic/pydantic-core/blob/main/src/inpu...

Thanks for pointing out to that, I did not know about it. Also attaching repo in case someone would be interested as well - https://github.com/pydantic/pydantic-core

pydantic-core: The core validation logic for pydantic, a Python data parsing and validation library.

pydandic-core [0] will hopefully solve this issue (written in Rust)

[0] -- https://github.com/pydantic/pydantic-core

LinkedIn influencers are weird lol. Rust v Python is apples and oranges. Rust would be glued together by python just like it does with C/C++ and Java/Spark today. We’re already seeing some packages go this direction, like pydantic v2 is rewriting its core validation in rust.

Author of typedload here!

FastAPI relies on (not so fast) pydantic, which is one of the slowest libraries in that category.

Don't expect to find such benchmarks on the pydantic documentation itself, but the competing libraries will have them.

[0] https://ltworf.github.io/typedload/

I wrote typedload, which is significantly faster than pydantic. Just uses normal dataclasses/attrs/NamedTuple, has a better API and is pure Python!

I read all the perftests in the repo. I think they nearly all parse a structure that contains a repetition of the same or similar thing a couple hundred thousand times times and the timing function returns the min and max of 5 attempts. I just picked one example for posting.

Not a Python expert, but could the Pydantic tests be possibly not realistic and/or misleading because they are using kwargs in __init__ [1] to parse the object instead of calling the parse_obj class method [2]? According to some PEPs [3], isn't Python creating a new dictionary for that parameter which would be included in the timing? That would be unfortunate if that accounted for the difference.

Something else I think about is if a performance test doesn't produce a side effect that is checked, a smart compiler or runtime could optimize the whole benchmark away. Or too easy for the CPU to do branch prediction, etc. I think I recall that happening to me in Java in the past, but probably not happened here in Python.

[1] https://github.com/ltworf/typedload/blob/37c72837e0a8fd5f350...

[2] https://docs.pydantic.dev/usage/models/#helper-functions

[3] https://peps.python.org/pep-0692/