Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Attrs – the Python library everyone needs (2016)

glyph.twistedmatrix.com

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Attrs – the Python library everyone needs (2016)

#101

Post by nauticacom »

masklinn wrote: post #87
nauticacom wrote: post #51

Earlier quoted context omitted.

I really, genuinely don't get the appeal. I don't follow the "less code = better" ideology so maybe that's a contributor but I really don't see how this: class Person: def __init__(self, name, age): self.name = name self.age = age is any worse than this: @dataclass class Person: name: str age: int I'm not writing an eq method or a repr method in most cases, so it just doesn't add much for the cost.

> I'm not writing an eq method or a repr method in most cases, so it just doesn't add much for the cost. Until you need them for debugging. And dataclasses make them free, at lesst syntactically.

I understand repr for debugging (though imo it's a deficiency of the language that custom objects don't have a repr which lists their attributes), but eq is a property of the domain itself; two objects are only equal if it makes sense in the domain logic for them to be equal, and in many cases that equality is more or less complicated than attribute equality.

Re: Attrs – the Python library everyone needs (2016)

#102

Post by masklinn »

nauticacom wrote: post #101
masklinn wrote: post #87

Earlier quoted context omitted.

> I'm not writing an eq method or a repr method in most cases, so it just doesn't add much for the cost. Until you need them for debugging. And dataclasses make them free, at lesst syntactically.

I understand repr for debugging (though imo it's a deficiency of the language that custom objects don't have a repr which lists their attributes), but eq is a property of the domain itself; two objects are only equal if it makes sense in the domain logic for them to be equal, and in many cases that equality is more or less complicated than attribute equality.

> though imo it's a deficiency of the language that custom objects don't have a repr which lists their attributes

It makes perfect sense that attributes be implementation details by default, and `@dataclass` is one of the ways to say they're not.

> eq is a property of the domain itself; two objects are only equal if it makes sense in the domain logic for them to be equal, and in many cases that equality is more or less complicated than attribute equality.

dataclass is intended for data holders, for which structural equality is an excellent default,

If you need a more bespoke business objects, then you probably should not use a dataclass.

Re: Attrs – the Python library everyone needs (2016)

#103

Post by ericvsmith »

masklinn wrote: post #102
nauticacom wrote: post #101

Earlier quoted context omitted.

I understand repr for debugging (though imo it's a deficiency of the language that custom objects don't have a repr which lists their attributes), but eq is a property of the domain itself; two objects are only equal if it makes sense in the domain logic for them to be equal, and in many cases that equality is more or less complicated than attribute equality.

> though imo it's a deficiency of the language that custom objects don't have a repr which lists their attributes It makes perfect sense that attributes be implementation details by default, and `@dataclass` is one of the ways to say they're not. > eq is a property of the domain itself; two objects are only equal if it makes sense in the domain logic for them to be equal, and in many cases that equality is more or le…

dataclasses makes it easy to just add your own `__eq__` method, if the default doesn't suit you. You just define it! Nothing else is required.

So I wouldn't be so quick to abandon dataclasses in such a case.

Re: Attrs – the Python library everyone needs (2016)

#104

Post by jhardy54 »

timost wrote: post #70
jhardy54 wrote: post #10

Earlier quoted context omitted.

Pydantic works with mypy, so you have validation at build-time and parsing at runtime.

Last time I checked. Constrained types do not work with mypy out of the box. https://github.com/samuelcolvin/pydantic/issues/975

Thanks! I didn’t know about that.

Re: Attrs – the Python library everyone needs (2016)

#105

Post by masklinn »

ericvsmith wrote: post #103
masklinn wrote: post #102

Earlier quoted context omitted.

> though imo it's a deficiency of the language that custom objects don't have a repr which lists their attributes It makes perfect sense that attributes be implementation details by default, and `@dataclass` is one of the ways to say they're not. > eq is a property of the domain itself; two objects are only equal if it makes sense in the domain logic for them to be equal, and in many cases that equality is more or le…

dataclasses makes it easy to just add your own `__eq__` method, if the default doesn't suit you. You just define it! Nothing else is required. So I wouldn't be so quick to abandon dataclasses in such a case.

> dataclasses makes it easy to just add your own `__eq__` method, if the default doesn't suit you. You just define it! Nothing else is required.

That's completely besides the point, and lots of non-data objects should not be equatable at all, if they even can technically be.

Re: Attrs – the Python library everyone needs (2016)

#106

Post by ericvsmith »

masklinn wrote: post #105
ericvsmith wrote: post #103

Earlier quoted context omitted.

dataclasses makes it easy to just add your own `__eq__` method, if the default doesn't suit you. You just define it! Nothing else is required. So I wouldn't be so quick to abandon dataclasses in such a case.

> dataclasses makes it easy to just add your own `__eq__` method, if the default doesn't suit you. You just define it! Nothing else is required. That's completely besides the point, and lots of non-data objects should not be equatable at all, if they even can technically be.

I don't understand your point. Are you saying that `__eq__` shouldn't be implemented at all? There's a switch for that, too.

Re: Attrs – the Python library everyone needs (2016)

#107

Post by nurettin »

ericvsmith wrote: post #89
nurettin wrote: post #81

Earlier quoted context omitted.

dataclasses have methods for iterating fields and inspecting types, so any feature can be added. There is also the benefit of type checking. My grief with dataclasses is how I can't inherit from dataclasses with default fields without making all child class fields also have defaults.

dataclasses author here. Does the keyword-only feature in 3.10 help you at all?

Love it, thank you!

Re: Attrs – the Python library everyone needs (2016)

#108

Post by masklinn »

ericvsmith wrote: post #106
masklinn wrote: post #105

Earlier quoted context omitted.

> dataclasses makes it easy to just add your own `__eq__` method, if the default doesn't suit you. You just define it! Nothing else is required. That's completely besides the point, and lots of non-data objects should not be equatable at all, if they even can technically be.

I don't understand your point. Are you saying that `__eq__` shouldn't be implemented at all? There's a switch for that, too.

I was merely noting that dataclasses are mostly intended for data holder objects (hence data classes), and thus defaulting to structural equality makes perfect sense, even ignoring it being overridable or disableable.

This was in reply to this objection:

> eq is a property of the domain itself; two objects are only equal if it makes sense in the domain logic for them to be equal, and in many cases that equality is more or less complicated than attribute equality.

Re: Attrs – the Python library everyone needs (2016)

#109

Post by glyph »

skrtskrt wrote: post #14
ahurmazda wrote: post #11

Earlier quoted context omitted.

Do you have concern with speed or memory footprint of pydantic compared to the rest (attrs, dataclasses etc)? Pydantic seems insistent on parsing/validating the types at runtime (which makes good sense for something like FastAPI).

We always used attrs with the runtime type validators anyway. Getting those types checked in Python was way more valuable to my teams than the minor boilerplate reduction. If you’re worried about the performance hit of extra crap happening at runtime… dear lord use another programming language. Dataclasses is just… meh. Pydantic and Attrs just have so many great features, I would never use dataclasses unless someone…

To the runtime-validation point; our team used attrs with runtime validation enforced everywhere (we even wrote our own wrapper to make it always use validation, with no boilerplate) and this ended up being a massive performance hit, to the point where it was showing up close to the top of most profile stats from our application. Ripping all that out made a significant improvement to interactive performance, with zero algorithmic improvements anywhere else. It really is very expensive to do this type of validation, and we weren't even doing "deep" validation (i.e. validating that `list[int]` really did include only `int` objects) which would have been even more expensive.

Python can be used quite successfully in high-performance environments if you are judicious about how you use it; set performance budgets, measure continuously, make sure to have vectorized interfaces, and have a tool on hand, like PyO3, Cython, or mypyc (you should probably NOT be using C these days, even if "rewrite in C" is the way this advice was phrased historically) ready to push very hot loops into something with higher performance when necessary. But if you redundantly validate everything's type on every invocation at runtime, it does eventually become untenable for anything but slow batch jobs if you have any significant volume of data.

Re: Attrs – the Python library everyone needs (2016)

#110

Post by glyph »

geofft wrote: post #55
avidphantasm wrote: post #29

Earlier quoted context omitted.

Yes. There needs to be a very good reason for me to pull in a third party library (in this day and age, given supply chain attacks, etc.). I don’t see what Attrs gives me that dataclasses does not.

Huh, it's the other way around for me. Just about every nontrivial Python project I write requires at least one third-party library, and one much more complicated than attrs at that, that I may as well use attrs too . All the complexity of having dependencies - both distributing them / setting up a virtualenv / etc., and whatever scrutiny I wish to do on dependencies - have a pretty big constant term from doing them…

Not that attrs or dataclasses has particularly significant attack surface, but when considering stdlib vs. 3rd-party you also have to consider the amount of maintenance and the release cadence. Attrs can release every few months if the rate of change demands it, whereas the stdlib has a fixed yearly release schedule that is tied to interpreter versions. Attrs has a small, focused development team whereas the stdlib is maintained by developers who are stretched very thin, and many packages within it are effectively abandoned. Upgrading dataclasses means upgrading everything in the stdlib at the same time, whereas attrs can be upgraded independently, by itself.

Supply chain attacks are a complex and nuanced topic so there are plenty of reasons to be thoughtful about adopting new dependencies, but it's definitely not as simple as "just use the stdlib for everything".

Post reply on HN