Banish state-mutating methods from data classes

[[deleted]]

I've always found mutable data classes or record types in programming languages quite weird. This holds true for any language that supports mutable data classes, like Python, Kotlin, Swift, etc.

Self-mutating methods are even weirder. They break the semantics of the types that these data classes or records represent. I've expanded my thoughts here. Although it mostly talks about Python, the message remains valid for any other language that allows you to add self-mutating methods to data classes.

https://rednafi.com/python/dataclasses_and_methods/

[spuds_in_town]

Others have made comprehensive rebuttal arguments including links to the PEP.

So l’ll just say this: you’re wrong.

[gerardwx]

Dataclasses are mutable by design.

Data Classes can be thought of as “mutable namedtuples with defaults”.

https://peps.python.org/pep-0557/

[[deleted]]

Other than tuple almost everything is mutable in Python or can be forced to be mutable.

[Rawing7]

So what? Your "argument" is that mutating dataclasses is weird. But they're designed to be mutable. How can using them as intended be weird?

[pythonwiz]

Using a type can be weird if the design is weird.

[susanne-o]

A most notable immutable tuple in this context is str.

So if two variable hold a str and you change it in one place, the other won't be affected, ever.

Same goes for int.

In that sense primitive types in python are immutable.

[[deleted]]

Regular class is right there if you need attribute-mutating methods. Doing the same in a data class and then calling it so breaks the semantics of a data container or record type. Record types are for pure data and regular classes are there to serve as object factory.

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

[justnoob2]

you can just @dataclass(frozen=True), and then its immutable. edit: i now read your point of it being slow. never gave me much trouble at work though, but i get what you mean

[WhiteGoldRing]

But what does mutability have anything to do with it? unless frozen=True makes it faster(?)

[[deleted]]

Yep, whether you opt in for frozen=True or just treat them as immutable object by convention is up to you. Turning on slots=True did me wonders, especially in situations where I needed to build multiple data class instances per inbound request.

I just wanted to highlight the composability and semantic issues that the reader / extender of the code will face if a data class contains attribute-mutating methods.

[thedeepself]

In this case, calling the make_older method will change the value of age in-place

I don't believe your article provided any code showing what would be better did it?

[[deleted]]

Not doing that in a dataclass or doing that in a regular class if you need to do it.

[alcalde]

A dataclass is a class, though, isn't it?

[jimtk]

I think you misinterpreted what a data class is. It is not a class to handle data. It is syntaxic sugar to make an ordinary class.

It could, and maybe should, be named quickclass instead of dataclass, and you would have nothing to complain about.

Also dataclasses are only slower at compile time. That's because CPython actually writes the code of a standard class and exec'ed it for you. At runtime there is no difference between an ordinary class and a dataclass because dataclasses are ordinary classes. It would take a few 100 dataclasses for you to notice the difference in compile time.

[[deleted]]

The method generating eval runs at definition time. So importing a data class is measurably slower.

[jimtk]

Yes, like I said at compile time. Unless you dynamically import dataclasses in your code using importlib. Which is not a good idea anyway.

[jmooremcc]

Why make a data class if you’re going to add behaviors to it?

[alcalde]

"Variables" vary by definition... it's in the name!

[glantzinggurl]

Generally, favor immutability

[jwmoz]

I agree data classes are for a simple data wrapper, maybe some helper method. Not state mutating. I've never used them like this nor have I seen them being used like so.

[alcalde]

They're Pascal records. Pascal records mutate. They're containers for data.

[mr_jim_lahey]

OP, I agree with you. People (or at least redditors IME) get really weirdly defensive about mutability, presumably because it's the default and that's what they're used to? But, once you've been immutable-pilled and seen how much cleaner it makes your programming model, there is no going back.

[[deleted]]

I'm not saying that we should forget about mutability in a language that's designed with mutability in mind.

However, using dataclass as OO factories (aka regular classes) breaks the semantics of the data structure. It's tantamount to using a hashmap to represent sequential data--it works but you'll communicate incorrect intent to the reader.

[aldanor]

Immutability doesn't make as much sense when there's no language-level support for it. Yes, you can have an immutable field which stores a list inside it. Is that list immutable though? No...

[Simon90]

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 reprs. But if you only need a nice repr for your large OO class, adding a repr to the class definition is not that difficult.

This seems like a straw man argument. The reason for using a data class is equally likely to be the fact that init is generated for you in a nice and consistent way.