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/OCXNXU7LP6Z4FSU4HHU3UM43H3SEEATV/
Code of Conduct: http://python.org/psf/codeofconduct/
