Live data from Hacker News

I use Attrs instead of Pydantic

threeofwands.com

51–60 of 76 posts

Re: I use Attrs instead of Pydantic

#51
post #33
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.

I think the comment about types takes a rather narrow view of Python use cases. Sure, if you’re some lone sysadmin using Python as an alternative to bash to implement some questionable ETL pipeline comprising a bunch of random scripts running off a single machine somewhere then I agree. You probably are not the target audience for type annotations. But even moderately complex libraries and applications are such a hug…

People in the data science world with dubious coding practices should keep their data in commonly used types such as Pandas tables. The last thing we should want from them is encoding their data with ill-conceived class/type systems. Not sure if that is what you mean.

I'd say Python's large scale adoption is exactly a good example of dynamic typing delivering on its promises.

Re: I use Attrs instead of Pydantic

#52
post #21

Having run into these issues with Pydantic, we've been using Mashumaro[1], which, while not having all the bells and whistles of Pydantic, has served us pretty well. 1: https://github.com/Fatal1ty/mashumaro

Isn't part of validation making sure you get the expected data in the expected format?

Re: I use Attrs instead of Pydantic

#53
post #36

Earlier quoted context omitted.

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…

Type hints just make everything so much easier. When you're writing a function, you _know_ that parameter is an int, or float, or something you can use a list comprehension on (iterable). Why not just say it right there in the function definition? It's better than writing it in a docstring, because a type checker will tell you to change the type if you change how you use a variable. Does everyone need to go all the w…

A sprinkling of type annotations to help with ambiguity is nice. However, I don't recall the last time I spent ages figuring out what type I need to pass to a function if it simply wants a builtin type. It's usually the semantics or a library-unique type (ugh!) that I have to look up.

Re: I use Attrs instead of Pydantic

#54
post #53

Earlier quoted context omitted.

Type hints just make everything so much easier. When you're writing a function, you _know_ that parameter is an int, or float, or something you can use a list comprehension on (iterable). Why not just say it right there in the function definition? It's better than writing it in a docstring, because a type checker will tell you to change the type if you change how you use a variable. Does everyone need to go all the w…

A sprinkling of type annotations to help with ambiguity is nice. However, I don't recall the last time I spent ages figuring out what type I need to pass to a function if it simply wants a builtin type. It's usually the semantics or a library-unique type (ugh!) that I have to look up.

Definitely. This to be especially terrible with some libraries (example: sqlalchemy) which have a crap load of types. You're not really sure what's being returned, etc.

Re: I use Attrs instead of Pydantic

#55

Earlier quoted context omitted.

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.

I want never to see the names attr.ib and attr.s in code that I am working on. So I don't understand how your suggestion solves the problem: it might not be me writing the code.

Re: I use Attrs instead of Pydantic

#56
post #34

That's just like, your opinion, man! I'm a die-hard pydantic fan, but it's refreshing to see other perspectives, while the author is acknowledging it is their opinion, without getting all holy-war. Also, they aren't orthogonal. Pydantic is definitely heavier than attrs in terms of processing. This is what makes pydantic a great bastion at shearing layers. "Validate all 10000 ints" is exactly what you want when parsin…

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…

SQLModel is brand new? why not just use sqlalchemy which is more mature?

Re: I use Attrs instead of Pydantic

#57
I'm just here to say I largely agree with the author.

I think a lot of this boils down to the functional approach that (c)attrs takes, vs Pydantic's OO. Because it's more functional, there's higher composability and more power given to the user.

On my team, we use cattrs and add our own customizations to it to great effect, and these simply would not be possible with Pydantic.

That said, there are reasons Pydantic seems to be ascendant despite attrs being the library that inspired dataclasses. It's very much a batteries-included library, which fits the ethos of Python.

Re: I use Attrs instead of Pydantic

#58

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.

Agreed. All my Go apps were written this way, it was nice to use Pydantic in a similar way. Especially in K8s, where most of my config is env vars.

Re: I use Attrs instead of Pydantic

#59
post #6

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…

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/

I use marshmallow-dataclass in an API client lib I've been continuously working on for a while for work.

It's great stuff, but I'm always looking for alternatives.

Re: I use Attrs instead of Pydantic

#60
post #34

That's just like, your opinion, man! I'm a die-hard pydantic fan, but it's refreshing to see other perspectives, while the author is acknowledging it is their opinion, without getting all holy-war. Also, they aren't orthogonal. Pydantic is definitely heavier than attrs in terms of processing. This is what makes pydantic a great bastion at shearing layers. "Validate all 10000 ints" is exactly what you want when parsin…

https://github.com/samuelcolvin/pydantic/pull/1568 If I'm reading this issue right the benchmarks in the pydantic docs are misleading

Also

> The author of this article (https://stefan.sofa-rockers.org/2020/05/29/attrs-dataclasses...) poits out that replacing dateutil.parser.parse function with datetime.isoformat increases performance of attrs in 7 times.

Post reply on HN