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
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] @wraps(cls.__init__) 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) self._dataclass_init(**dataclass_kw) super_.__init__(self, *args, **kw) cls.__init__ = __init__ return cls
```
https://gist.github.com/jsbueno/5a207e6a2c6c433a7549c78ba2edab7d
On Wed, 15 Apr 2020 at 16:40, Andrew Barnert via Python-ideas < python-ideas@python.org> 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 -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/27CGQQ... Code of Conduct: http://python.org/psf/codeofconduct/