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/
