I use Attrs instead of Pydantic • Hacker News Board

Re: I use Attrs instead of Pydantic

#41

Post by radus » Thu, Aug 26, 2021, 1:25 PM UTC

andrewingram wrote: post #8

zo1 wrote: post #6

Earlier quoted context omitted.

You could have a look at Marshmallow perhaps? I use it to great effect with marshmallow-dataclass so I don't have to define the boiler-plate data classes separately to the validation/schema. Essentially the dataclass (with type-hints) becomes the data-validation specification. Links: https://pypi.org/project/marshmallow-dataclass/ https://pypi.org/project/marshmallow/

Thanks, I've had a look at Marshmallow in the past, but it's still doing the extra bits of dealing with the extra bits of serialization, it never really felt all that dissimilar to Pydantic. What I've really been looking for something that I can just use to check a data structure i'm passing in to a function call is valid. One use case is related to state machines, where I'm providing some data along with a transitio…

Pedantic has a validate_arguments decorator that while in beta, I think does what you want: https://pydantic-docs.helpmanual.io/usage/validation_decorat...

Re: I use Attrs instead of Pydantic

#42

Post by HelloNurse » Thu, Aug 26, 2021, 1:28 PM UTC

da39a3ee wrote: post #18

kubami wrote: post #16

Earlier quoted context omitted.

The `attrs` authors address it in the documentation: https://www.attrs.org/en/stable/overview.html#on-the-attr-s-... At first, some people have a negative gut reaction to that; resembling the reactions to Python’s significant whitespace. And as with that, once one gets used to it, the readability and explicitness of that API prevails and delights. For those who can’t swallow that API at all, attrs comes with serious…

Yes, I know. That doesn’t redeem it. I want never to have to read those names in python code I'm working with; the documentation entry doesn't achieve that. And anyway, the library is called “attrs”, so why is it imported as “attr”?

If it is a problem,

  import attr as attrs

which is probably what I would do for consistency.

Re: I use Attrs instead of Pydantic

#43

Post by prionassembly » Thu, Aug 26, 2021, 1:37 PM UTC

andrewingram wrote: post #5

I'm a bit confused, because I ultimately understood Attrs and Pydantic to be aimed at solving different problems. I may've been wrong, but my understanding was that: * Attrs - To reduce the boilerplate of defining classes, pre-dates dataclasses, but still has a bunch of capabilities that dataclasses don't. * Pydantic - A declarative data validation + [de]serialization tool, mostly to be used at the boundaries between…

Pydantic's "BaseSettings" has pretty much cured the evergreen itch of writing my own configuration languages. I love that env vars automatically override default values.

Re: I use Attrs instead of Pydantic

#44

Post by teajunky » Thu, Aug 26, 2021, 1:38 PM UTC

The author of the article is very biased because he is also the (co-)author of these libraries.

Personally I think that is not the fine way to bash other projects in the open source community. Clearly, attrs+cattrs and pydantic focus on different things. Let us all live together peacefully :)

Re: I use Attrs instead of Pydantic

#45

Post by bilboa » Thu, Aug 26, 2021, 1:40 PM UTC

andrewingram wrote: post #8

zo1 wrote: post #6

Earlier quoted context omitted.

You could have a look at Marshmallow perhaps? I use it to great effect with marshmallow-dataclass so I don't have to define the boiler-plate data classes separately to the validation/schema. Essentially the dataclass (with type-hints) becomes the data-validation specification. Links: https://pypi.org/project/marshmallow-dataclass/ https://pypi.org/project/marshmallow/

Thanks, I've had a look at Marshmallow in the past, but it's still doing the extra bits of dealing with the extra bits of serialization, it never really felt all that dissimilar to Pydantic. What I've really been looking for something that I can just use to check a data structure i'm passing in to a function call is valid. One use case is related to state machines, where I'm providing some data along with a transitio…

Sounds like you want jsonschema.

Re: I use Attrs instead of Pydantic

#46

Post by quietbritishjim » Thu, Aug 26, 2021, 1:52 PM UTC

A little off topic, but the article mentions:

> There are three reasons to use dataclasses over attrs:

Another, not in this list, is that since it is in the standard library, co-workers/contributors are significantly more likely to have heard of dataclasses and already know its interface. Another reason, sort of along similar lines, is the fact that that dataclasses has fewer features than attrs - the author mentions this as a disadvantage, but actually it's a benefit if it has the features you need, because a simpler library is less cognative overhead to write and maintain code against.

Re: I use Attrs instead of Pydantic

#47

Post by mumblemumble » Thu, Aug 26, 2021, 2:14 PM UTC

teajunky wrote: post #44

The author of the article is very biased because he is also the (co-)author of these libraries. Personally I think that is not the fine way to bash other projects in the open source community. Clearly, attrs+cattrs and pydantic focus on different things. Let us all live together peacefully :)

To your first point, that's the third sentence of the article itself.

To your second, I struggle to see this as bashing. It's certainly not an objective comparison, but it is about as even-handed a comparison as I'd be willing to ask of a mere mortal when they're also personally invested in the subject. You don't see sentences like, "Pydantic is wrong!" you see ones like, "Pydantic is very opinionated about the things it does, and I simply disagree with a lot of its opinions," or, "I disagree with this. Un/structuring should be handled independently of the model." That's not bashing; that's constructive criticism. It's worth noting that he also acknowledges that Pydantic does some things better.

For my part, I think my only real complaint about this article is that he doesn't really pay enough attention to the fact that, despite their overlapping functionality, (c)attrs and Pydantic are optimizing for very different use cases. That leaves me thinking that some (though far from all) of his criticism has a certain, "This screwdriver isn't very good at driving nails," characteristic.

Re: I use Attrs instead of Pydantic

#48

Post by zbentley » Thu, Aug 26, 2021, 2:16 PM UTC

maleldil wrote: post #37

nerdponx wrote: post #35

Earlier quoted context omitted.

As of 2021, there is now a complete Pydantic "CRUD stack" (ODMantic/SQLModel + FastAPI) that is ridiculously easy to get up and running with, and it has all of the features one might want in a brave new type safe world. By comparison, the system of tools around Attrs and Cattrs is a bit scattered and underdeveloped. I don't think there's a technical reason for it, that's just how it happened. It would be great to see…

What's the use case for Attrs in a post-dataclasses world? I use dataclasses all the time, and I've never felt the need to reach for Attrs. What am I missing out on?

Substantially more customization hooks in attrs.

Re: I use Attrs instead of Pydantic

#49

Post by mumblemumble » Thu, Aug 26, 2021, 2:29 PM UTC

quietbritishjim wrote: post #46

A little off topic, but the article mentions: > There are three reasons to use dataclasses over attrs: Another, not in this list, is that since it is in the standard library, co-workers/contributors are significantly more likely to have heard of dataclasses and already know its interface. Another reason, sort of along similar lines, is the fact that that dataclasses has fewer features than attrs - the author mentions…

One nice thing about making this decision is that the decision rubric for choosing between dataclasses and attrs is really straightforward. In addition to all the reasons the article lists for why you might need to use dataclasses, I'd personally also default to them unless I know I need one of the things that attrs does better: robust validation, or performance.

The nice thing here is that, since dataclasses are more-or-less just slimmed-down attrs, it's relatively easy to migrate from dataclasses to attrs at a later date.

Re: I use Attrs instead of Pydantic

#50

Post by janto » Thu, Aug 26, 2021, 2:51 PM UTC

kortex wrote: post #36

janto wrote: post #19

Earlier quoted context omitted.

Yes, this higher abstractions tendency is clearly away from "Flat is better than nested". Creating good abstractions is so difficult (and important) that it should not be done lightly by everyone. The recent proliferation of type annotations is also trending towards the static typing mindset, which is also cargo culting on a massive scale.

Static typing in python isn't "cargo culting." In fact I'd go even farther in the opposite direction, and say that if you are using python for production software engineering, and aren't typing most (>50%) of your function signatures, you are wasting everybody's time, your teams', code reviewers', and most of all your own time. Opinion, but empirical experience bears this out for me. I'm not talking mypy --strict her…

The problem with creating excessive types in production systems (which is what I want people to avoid and can happen if you go too far with Pydantic models + type annotations into pseudo-"static typing") is that you move outside the area that Python's core is already designed to generically cover in idiomatic ways. You end up wasting your own (and reviewers') time creating unnecessary code that future you will have to now maintain and extend to more generic cases.

I'm skeptical that the people that produce the kind of abomination you encountered would produce something less horrible if they went to town with static typing. I've seen too much Java to fall for that ;) I'm not averse to putting in some annotations and data validation chokepoints here and there.

I'd ask Steve why he called it `foo(bar)` rather than `set_width(width)`. Static typing fans shift the semantics of code onto a type system. I'd prefer it if they focused more on better naming than spending time on designing complicated Pydantic models.