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 c

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.