21 ms·

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 p

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.

masklinn 5y ago
> 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.
- ericvsmith 5y ago
  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.
  - masklinn 5y ago
    > 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.
    - ericvsmith 5y ago
      I don't understand your point. Are you saying that `__eq__` shouldn't be implemented at all? There's a switch for that, too.
      - masklinn 5y ago
        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.

masklinn 5y ago

> 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.

ericvsmith 5y ago
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.
- masklinn 5y ago
  > 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.
  - ericvsmith 5y ago
    I don't understand your point. Are you saying that `__eq__` shouldn't be implemented at all? There's a switch for that, too.
    - masklinn 5y ago
      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.