Which is what the OP is after.
Hmm, makes me wonder if there should be an option to define a __pre_init__ method.
Then you could customize the signature, but still use data classes nifty features for the primary __init__
And no, I haven’t thought this out, it would be tricky, and maybe impossible.
Which brings me back to the suggestion in a PR:
Optional have the __init__ accept *args, *kwargs, and then store them in self. Then users could do whatever they like with them in __post_init
-Chris
It becomes more painful the more parameters the parent has- parameters which the dataclass may not even care about. It not only makes the class definition long, it adds so these additional parameters to the init signature, which is icky for introspection and discoverability. Lots of "What the heck is this parameter doing here?" head scratching for future me (because I forget everything).
There's currently not a very compelling solution, AFAIK, to be able to use dataclasses in these kinds of situations ("these kinds" = any situation other than the most simple) other than the solution Christopher Barker suggested: using a mixin approach that treats the dataclass parameters specially. So I just haven't.
I did write a decorator of my own that replaces the dataclass init with one that calls super().__init__(*args, **kwargs) first before proceeding with the one written by dataclasses... I can't find it at the moment. But that has its own problems; one being the IDE doesn't know the init has been rewritten this way and so will complain about parameters sent to the dataclass that it doesn't know about.