cattrs VS pydantic

I'm fond of attrs and cattrs myself, attrs make creating data classes a snap, writing all of the stupid code python requires to have a dataclass. Note the new built in dataclass is actually a limited copy of attrs. https://www.attrs.org/en/stable/ and https://github.com/python-attrs/cattrs

This month, I've released version 0.17, and it's now blazing fast; there is in fact no more comparison with Pydantic, which more than 5x slower (up to 30x in serialization). It's also faster than alternatives like mashumaro or cattrs. (See the quick benchmark result in documentation, and the code)

```

Cattrs has some problems with generics [1] [2]. Dacite and marshmallow-dataclasses don't support generics well either, with some issues around Union types.

They do work well for simple python types but what I'd like to see is guarantee that the serialisation operation is completely reversible and if not raise warning/exception.

[1] https://github.com/Tinche/cattrs/issues/149

Yea everything is built from inspect up.Pydantic takes that and builds a class out of it. There are some strange side effects from that process that are non obvious especially when paired with how fastapi does their dependency injection creates some non obvious items. These items are very hard to modify.

I'd say you're on the right track with dataclasses, but it might be easier to use Pydantic.

It's not exactly the same thing but maybe Pydantic could be useful?

Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

> type hints are not binding.

There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

> Type checking is your job after all, ...[and that] requires maintenance.

There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

> There is an Any type and it renders everything useless

I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

> Duck type compatibility of int and float

The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

> Most projects need third-party type hints

Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

> Sadly, dataclasses ignore type hints as well

Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

> Type inference and lazy programmers

The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

> Exceptions are not covered [like Java]

I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.

[0] https://github.com/RussBaz/enforce

[1] https://github.com/agronholm/typeguard

[2] https://github.com/microsoft/pyright

[3] https://pydantic-docs.helpmanual.io

[4] https://github.com/tiangolo/fastapi

[5] https://github.com/microsoft/pyright/blob/main/docs/configur...

[6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...

I’d say take a look through Pydantic, lots of metaclassing in there. In particular with constrained numbers

The main.py module is in charge of exposing our FastAPI methods. As an example, this is the method for training a bot. It relies on Pydantic to facilitate the processing of the JSON input and output parameters. Parameter types are the dto version of the dsl classes.

Sorry, I was very unclear. They were going to postpone evaluation of annotations, breaking Pydantic notwithstanding some big efforts. See https://github.com/samuelcolvin/pydantic/issues/2678

FastAPI, on the other hand, gives us the Pydantic library to use, which makes data validation much simpler and faster than typing it by hand. It’s closely related to FastAPI itself, so we can be sure that Pydantic will be compatible with our framework at all times.

Model binding for requests and response with additional model validation features provided by Pydantic.