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 <jsbu...@python.org.br> 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] > @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 <br...@python.org> wrote: >> >> >> On Wed, Apr 15, 2020 at 8:45 AM Christopher Barker <python...@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. >> >> >> 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-le...@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/27CGQQY63GEBDNNU6MYYOY6YS63VZFQU/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/RP5LEXLJ4WTXIK2OBSGGVNRTUQ6UJP3U/ Code of Conduct: http://python.org/psf/codeofconduct/