Data Classification: Does Python still have a need for class without dataclass?

Using dataclass for all basic state classes whose primary purpose is public state with sensible init makes sense. But for the many other purposes of classes that need custom init, advanced field defaults, no equality, custom repr/str, advanced inheritance, etc dataclasses give you nothing but a bunch of magic to turn off or work around.

Whether you're using Kotlin data class, a C# record, a Scala case class, or whatever, we've seen in practice that these are only good for (often immutable) public state and data composition. Business objects with more logic and more than simple state/member manipulation are only hampered by dataclass field approaches. If Python embraced immutability and composition more at its core, then using dataclasses in these cases would make more sense.

As a Python instructor, classes are a pain in general to teach. OO seems to have a non-understandable aura around it. Especially for folks without a CS background. self is weird until you explain that __init__ is not really a constructor. We get through it but there are bumps in the road.

I don't teach dataclasses until I teach intermediate classes because I like my students to understand decorators beforehand.

This make me wonder if I should experiment with teaching dataclasses instead of __init__ (and just hand-wave decorators and types)...

To answer the question of the author, yes compatibility is sufficient reason not to do this. Please don't push this idea. I also don't agree with much of the reasoning or conclusions but others have identified many of the reasons elsewhere so I won't repeat them.

I think:

    data Point3D(x, y, z) from Vector: ...

is a terrible syntax, there are plenty of legitimate use cases where you'd have an overwhelming amount of fields in a class/structure, and listing them line by line (as well as explicitly specifying accessors to handle the couple special cases) would end up much more readable. I'd rather see something more along these lines:

    data Parrot(Animal):
        name
        age: int
        alive: bool = False
        purchased_in: Shop | None = field(default_factory=get_shop)
        ...

(Move "field" to builtins, etc.)

But overall this proposal seems like a no-brainer, even before the addition of the match statement. The "classic" __init__ is a jarring violation of DRY, baked right into one of the most common idioms in the language, and gets in the way of not just the "QoL" features like destructuring or type checking, but also of the efforts to build more efficient implementations that could pre-allocate object memory without speculative analysis, or optimise the dict lookup away.

The question is not "shall we", but "why wasn't it done in 2008".

Python is a multi-paradigm language.

And not only that, I think there are many reasons to want to continue having non-dataclass classes. Dataclass fits best with record-type data and not with encapsulated data or classes with mostly private attributes.

For my general uses, pydantic and dataclasses are very similar, and I prefer pydantic over dataclass for the following reasons:

1. pydantic by default ignores extra fields - it's useful when I make an API call and want to extract and validate only certain fields from the response, while dataclasses throws errors if you don't specify all fields, and this behavior can't be disabled

2. pydantic is more customizable - I can overwrite the BaseModel if I have a custom need

3. pydantic seems to integrate better with python typing - I'm not sure how to explain this one, but it feels more natural and dynamic

I'm not sure what the performance concerns are, though

I enjoy novel ideas, they are fun to entertain, but this is quite spicy of a take. I kind of understand where OP is coming from, but if you start to understand python internals, you would quickly see why it's completely untenable.

    data Point3D(x, y, z) from Vector:

is never, ever, ever, ever gonna happen. It's ugly, alien to the rest of python style, will be a massive pain to implement in the lexer/parser, adds another keyword and mechanism, and most importantly, makes the word "data" unusable as a variable name. Dataclasses are "just" decorator functions (there is some special optimization and meta magic under the hood, but still just a callable).

There's a glaring reason why we can't "just make all classes dataclasses" - it would break the entire data model of the language. "class" keyword is basically syntactic sugar for the "type" builtin. Everything (with a few small exceptions) you touch in python is a subclass of object. Changing the behavior of class to by default behave like dataclass would have knock-on effects across the entire language on every single python3 codebase on the planet.

Ok, even assuming we could surmount the insurmountable breaking changes, would we even want default classes to be dataclasses? Not in the slightest. Python may not have true private variables, but libraries/APIs leverage dunders, properties, and hidden state to do all kinds of OOPy things. You can't do that with dataclasses. Many times you have objects bound to attributes which don't have concrete types, such as endpoints in HTTP frameworks and anything with dynamic dispatch (yeah there's Callable, but it is tricky to type check).

Dataclass also has a self-documentation effect: it says "this thing is kind of like a record". Not a primitive, not a function, not a router, view, thread, tree node, god-class or stack frame. If I see dataclass, I almost always expect to be able to de/serialize it to some sort of message. Complex state, anything unpickleable, or exotic types don't really belong in a dataclass.

Integrating `dataclass` more into the language builtins might be nice, if only that it may allow/encourage a more native and performant implementation. Using a dataclass right now results in slightly slower class operations than handwritten types, and much slower import times.

I maintain another dataclass-like library[1] that's written fully as a C extension. Moving this code to C means these types are typically 5-10x faster for common operations[2]. It'd be nice if the builtin dataclasses were equally performant.

[1]: https://github.com/jcrist/msgspec

[2]: https://jcristharif.com/msgspec/benchmarks.html#benchmark-st...

Dataclasses are nice but they have a big downside: extending a dataclass with a default property can raise an error.

If you run this code:

    import dataclasses

    @dataclasses.dataclass
    class Base:
        a: int
        b: int = 1

    @dataclasses.dataclass
    class Child(Base):
        c: int

Then you'll get this error:

  TypeError: non-default argument 'c' follows default argument

I think the difficulty here is that data classes beyond the most simple cases have awkward extension points, see the docs on post-initialization https://docs.python.org/3/library/dataclasses.html#post-init...

I am partial to a dataclass keyword but… it’s tough. The problem with declarative stuff like this is that sometimes you really just want to do things in a certain order and now you have to communicate that (the keyword argument hack is an example of this)

Kind of a radical idea but IMHO in a high-level language (i.e. not C++ or Rust) the real mistake is structs/classes with mutable fields. None of those problems exist in that world.

It's not very ergonomic, but if you start from that assumption you could have ad-hoc syntactic support that desugars to a limited version of an optics library.

I still don't understand why you would use classes without methods. That's what dicts are for.

About 10 years ago someone who I thought was pretty smart said it was because dots are nicer to type, fair enough I guess. It just always seemed silly to me to go through setting up a class but not getting the benefits of using methods.

Having to specify the names and, if you hate yourself, the types of class members up front is a major limitation. Only when it is possible to do so (because the class is a boring one) the repetitiveness of typical __init__ methods can become an issue.

If you are defining dataclasses, do yourself a favor and define them kw_only=True.

For one category of classes-- representing data-- there's little point in non-dataclass classes. But for other kinds of classes, it's important to be able to control the constructor/dependencies. For example, suppose I have a provider class that abstracts the interface to some external system. My system needs to operate in at least 3 different contexts for this data provider: 1) connecting to an external database, 2) connecting to the local filesystem for simulations and experiments, and 3) unit tests. I have several implementations of this class using different mechanisms. Each of these take different things in their constructor: one takes a database connection as a dependency, another takes a directory name for the local filesystem, and another takes an in-memory dictionary or maybe doesn't need anything in its constructor.

Having each of these classes have a clearly defined type-annotated constructor makes a lot of sense and makes things more self-documented. If everything were a dataclass then this situation would not be explicitly stated in the constructors.

I think of dataclasses as glorified tabular data that is not of size to justify numpy.

Once the need to tart up the class methods or do any inheritance crops up, make a "proper" class.

None of that has an technical basis, but there is value in being methodical with the coding choices.

Probably a controversial opinion, but I would like `self` removed, and have the class body be an init function. Something like:

```

dataclass NormalizedPoint(x: float, y: float):

    _norm = math.sqrt(x\*2 + y\*2)
    x /= _norm    
    y /= _norm

    def __add__(other: NormalizedPoint):
        return NormalizedPoint(x + other.x, y + other.y)

```

In other words, I would really like some construct which sticks as close as possible to a normal function, but that also returns a (typed) object with everything in its scope.

If we get rid of normal classes, how do things like Django ORM work?

It's a pretty significant package, if you're proposing this kind of thing, I assume there's an answer to this...

Maybe I didn't have enough coffee, but what's really the point of "data" keyword? Seems like its only goal is to confuse. So you write that data thingy and later figure out you actually need a class, then what?

What's the difference between data and class? Because of what it keeps? So why not have "methods" for classes that only have methods or "notdecided" if you don't yet know what sort of class you are going to end up with.

I don't follow.

There's all kinds of use cases for classes without dataclass. For example, just the other day I wrote a leaky bucket rate limiter class. It uses the __aenter__ and __aexit__ methods to do things in async with blocks.

I love dataclasses, but there needs to be a compelling reason to break everyone's code and the reason can't just be "I don't want one import and one decorator".

Have been using python since python 1.x, I find data classes kind of nice bringing in convenience at the same time it is a weird hybrid. I would have rather have some native struct and variant (think rust neun) types which would have required new syntax

In a way it feels like data classes are a strange hybrid.

Similarly I see all kinds of type theoretical issues with type checking popping up.

It's just unfortunately becoming clear Python is going the way of C++.

This would have been a good discussion 10 years ago, but these days it's pydantic first, hardly ever use dataclass

Would switching all classes to the data class style mean losing the ability to differentiate between class variables and object variables?

I'm going to go try it in a minute, but I'm specifically thinking of setting a mutable variable to use as a way to cache the results of a long running process across objects. Or even just any variable to use with class methods. I'll update soon

edit:

I tried it out and it looks like it works just fine

    @dataclass
    class MyCoolDataClass:
        arg: any
        _things = {'last_updated':0, 'data':[]}
        _things_timeout = 300


        def _update_things(self):
            """some long process"""
            time.sleep(10)
            self._things['last_updated'] = time.time()
            self._things['data'] = ['some things']
        @property
        def things(self):
            seconds_since = time.time() - self._things.get('last_updated', 0) 
            if seconds_since >= self._things_timeout:
                self._update_things()
            return self._things.get('data',[])

which then works as expected, sharing the cache between objects.

    start_time = time.time()
    for i in range(10):
        obj = MyCoolDataClass(i)
        print(obj.things, int(time.time() - start_time))

    ['some things'] 10
    ['some things'] 10
    ...

So yeah, I think I might be on board with dataclasses by default. As long as we can still add __init__ for when we want to do something extra with the variable

edit2:

If we switch to dataclasses things like this would need to raise a syntax error:

    @dataclass
    class MyOtherDataClass:
        arg: any
        def __init__(self, special_arg:str):
            self.special_arg = special_arg.lower().strip()

As it stands now defining __init__ completely removes any definitions set in the class.

I think the killer feature would be if we added django forms style validate methods for validation and normalization. imagine if we could do this:

    class Drink:
        temp: str
        container: str

        def _validate_temp(self, temp):
            temp = temp.strip().lower()
            if temp not in ['hot', 'cold', 'room']:
                raise ValidationError(f'"{temp}" is not a valid temperature')
            return temp

        def _validate_container(self, container):
            container = temp.strip().lower()
            if container not in ['mug', 'glass' 'sippy cup']:
                raise ValidationError(f'"{container} is not a valid container")
            return container

        def _validate(self, kwargs):
            if kwargs['temp'] == 'cold' and kwargs['container'] == 'mug':
                raise ValidationError("Don't dirty a mug for a cold drink!")
            

Sure, it goes against explicit is better than implicit, but that could be fixed with decorators. It would also be nice to have a concise way to say what values are valid, and a handful of standard normalization processes, but I think you get the idea.

Does Java still have a use for variables without final?

Does Javascript still have a use for functions without async/await?

This is just a repackaging of an age-old argument, imo.

When they invented the screw, it did not preclude the nail. /shrug

I'm always astonished by Python. For ages "dataclasses" have been called struct or record in other languages and are fast first class values.

In Python, they invent a weird, slow concept and discuss it for a decade, probably while writing 10 PEPs in the process. Through conferences, Stackoverflow, etc. people are slowly convinced that the concept is natural.