On Wed, Apr 15, 2020 at 8:45 AM Christopher Barker <pythonchb@gmail.com> wrote:
> you'd just add *args and **kwargs to the init signature and call super().__init__(*args, **kwargs).

Which is what the OP is after. 

Hmm, makes me wonder if there should be an option to define a __pre_init__ method. 

Also note that the 'attr' package on PyPI is still available and provides features that dataclasses do not. Generalizing something in the stdlib is not always the best/necessary solution, especially if there's a battle-tested alternative available on PyPI.


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


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. 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TH4I7L5FMDEAHCLN7EE3DZFZFPPXG5GH/
Code of Conduct: http://python.org/psf/codeofconduct/