typedload

> This is simply not true. So sad. Ah sorry, so, just coincidentally pydantic happened to be slower than any other library that had a PR to be added to the benchmark, but that was not the reason they were rejected. Better now? > Please show me a sensible benchmark where your library is faster than pydantic? $ python3 perftest/realistic\ union\ of\ objects\ as\ namedtuple.py --pydantic (1.2192879340145737, 1.2595951650291681) $ python3 perftest/realistic\ union\ of\ objects\ as\ namedtuple.py --typedload (1.0874736839905381, 1.114147917018272) I'm not a math genius but I'm fairly sure that 1.08 is less than 1.21. So much for your invite to be gentle and cooperative :D (https://github.com/ltworf/typedload/pull/422)

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 t

The perf part of the tests just seems to be a microbenchmark for seeing how fast the various frameworks can parse a 30000x300 dict of strings representing numbers [1]. If that is all one's application does, and can use your library in their organization/team, that's great. However a 2-3x performance boost for the parsing stage for a use case like an API call might not matter when that could be overshadowed by validation and/or upstream API calls. A realistic app would likely use a validation library like Pydantic's [2] to throw a custom typed-error that can be processed, e.g., localization, before returning it downstream. [1] https://github.com/ltworf/typedload/blob/37c72837e0a8fd5f350... [2] https://docs.pydantic.dev/usage/validators/