Scanning the messages, I met this from Ricky Teachey:

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. 

yep. My approach is the same and will fail the same way - but that is only so much IDEs can go 
if they keep tring to statically guess parameters to a class' __init__ . Anyway, I think it is a way to go if one
needs the collaborative dataclasses now.


On Wed, 15 Apr 2020 at 17:45, Joao S. O. Bueno <> wrote:
There is a way to have dataclasses as they are now behave collaboratively  with
a further decorator.

For Python 3.8 livefcycle such decorator could live in an external package - 
if its good, it could go into the stdlib, or maybe, another
"dataclasses.collaborative_dataclass"  would already create a collaborative
dataclass without breaking backwards compatibility.

here is some sample code, I've tested locally:

def colaborative(cls):
    if not hasattr(cls, "__dataclass_fields__") or not "__init__" in cls.__dict__:
        return cls
    cls._dataclass_init = cls.__init__
    super_ = cls.__mro__[1]
    def __init__(self, *args, **kw):
        # use inspect.signature stuff to proper retrieve 'args' into dataclass kw if needed, else:
        dataclass_kw = {}
        for key, value in list(kw.items()):
            if key in cls.__annotations__:
                dataclass_kw[key] = kw.pop(key)
        super_.__init__(self, *args, **kw)
    cls.__init__ = __init__
    return cls   


On Wed, 15 Apr 2020 at 16:40, Andrew Barnert via Python-ideas <> wrote:
On Apr 15, 2020, at 10:16, Brett Cannon <> wrote:

On Wed, Apr 15, 2020 at 8:45 AM Christopher Barker <> 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.

Wasn’t dataclass designed with customization/extension hooks for apps or libraries to use, like the field metadata? Are any libs on PyPI taking advantage of that? If not, maybe this would be a good test case for that functionality. If it turns out to be easy and obvious, then as soon as someone’s got something stable and popular, it could be proposed for a merge into the stdlib—but if it turns out that there are multiple good ways to handle it they could stay as competitors on PyPI forever, while if it turns out that the extension hooks aren’t sufficient, someone could propose exactly what needs to be changed to make the extension writable.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: