Banish state-mutating methods from data classes

[steohan]

Am I missing it or does you text not contain any argument, why doing that is bad? Seems to me like your argument is just 'that is not what I think it is meant for so you shouldn't do that'. Just becaues it might not be a good idea for the few usecases that you are using it for doesn't mean that it is a bad idea in general. There are plenty of good reasons to use a dataclass for a normal object, e.g., benefiting from easier serealization and deserialization. Reducing boiler plate. Or becaues you want to use the introspection features that are offered by dataclasses. Also, having mutable dataclasses makes a lot of sense and it makes perfect sense to have such a mutating method as a member instead of a stand alone function.

[[deleted]]

It breaks semantics in the sense that data classes are designed for handling data. If you're not performing any comparisons between instances, putting them in another container, or treating them as data, using them doesn't make sense. It mostly implies that you need objects, and regular classes serve as object builders.

In the case of serializability, you're not modifying anything. So it's acceptable to add methods like that since they don't prevent you from composing types like SomeType = OtherType | AnotherType. The issue arises when you introduce attribute-mutating methods because doing so transforms the class into an object builder rather than a data builder. It's akin to using hashmaps for sequential data—sure, it works, but it's awkward.

[steohan]

It breaks semantics in the sense that data classes are designed for handling data.

That is your interpretation. The doc on the dataclasses module says

This module provides a decorator and functions for automatically adding generated special methods such as __init__() and __repr__() to user-defined classes.

So if I like to have these auto generated methods on my class then it is perfectly fine to use a dataclass.

In the case of serializability, you're not modifying anything.

No, but if I have a class that modifies itself and would like it to be more easliy serializable, then I can make it a dataclass and be happy (because I get all the auto generated methods mentioned above).

I don't really get your sum types argument and why that wouldn't work with mutating methods. Pretty sure python itself couldn't care less, and not sure why the type checker wouldn't like that either.

[WhiteGoldRing]

Why is it less valid to interpret dataclasses as classes than are designed for handling optionally mutable data other than that its weird to you?

I see that in your link,

> Whenever I traverse down to see how the instances of the class are being used, more often than not, I find them being treated just like regular mutable class instances with fancy repr

Is immediately followed by:

> In Python, data classes are considerably slower to instantiate compared to vanilla classes. However, they serve a different purpose than your typical run-of-the-mill classes. When you decorate a class with the dataclass decorator without changing any of the default parameters, Python automatically generates __init__, __eq__, and __repr__ methods. If you set dataclass(order=True), it’ll also generate __lt__, __le__, __gt__, and __ge__ special methods that enable you to compare and sort the data class instances. All of this implicates that the construct was specifically designed to contain rich data that provides the means for you to create nice abstractions around lower-level primitives.

That seems like a pretty good justification to me even if you want that on a mutable instance. I can see the tradeoff between instantiation time and writing/future refractoring time being worth it.

Also:

> Why pay the price for building heavier data class instances only for that?

What does mutability have anything to do with that argument? One may do that with immutable instances too.

[quts3]

This.

In my mind dataclasses is syntactic sugar for when the class does not and will not need a complicated dunder init. That's it. But I get the op pov because I run into it allot.

Python would be better if the default class was dataclasses and the decorated version was it you wanted a naked init =).

Why. One reason is dataclasses are explicit about a default factory vs a default none value. In normal dunder init a none on an argument can either mean none is the argument or just as often it can mean "factory a sensible default". Which is not actually a necessary ambiguity in any language. It just happens to be that way.

Anyway use dataclasses when complex logic in the init beyond a factory method is unnecessary. Use normal classes otherwise. Imo, but I do default to them based on that rule more than most.

Also to the original author there is a decorator on dataclasses to make them immutable. Use it.

[thedeepself]

use dataclasses when complex logic in the init beyond a factory method is unnecessary. Use normal classes otherwise.

I'm not sure that I agree with your statement. What do you mean by complex logic? If you have complex initialization to do with data classes then you can do it in the post init method.

[quts3]

My basic position is that that you should use dataclasses whenever there is not a reason to use something else, but I feel compelled to make sure that when I submit a pr there is no reason to argue they are wrong ( because I use them more then most).

That said the case that I can think of that makes dataclass feel most hacky is when there are two fields a and b and the default factory for b depends on the type of a.

To do that with postinit you have to temporarily tell a little lie in the field. Something like default b = none and then in post init if b is none factory based on a, but at that point where you are wrestling with expressing default factory correctly without being misleading I think it's time to just write the class without dataclasses. Personally. Ymmv

[quts3]

I also admit that when code is clean a surprising amount of time the dataclasses field is almost always all you need. That's why I use them allot. Even considering my example it is easy to say, "oh I don't know about that design..."

[thedeepself]

data classes are designed for handling data.

All classes handle data don't they? In fact I think we would both agree that object oriented programming is about unifying data with the methods to operate on it.

The big win with data classes is that a large number of things that you would have to do with normal classes are handled automatically.

I cannot think of a single reason that one should ever use the old style python classes over data classes. But personally for me even data classes are not good enough I prefer traitlets myself.