For simple situations you can call super in the __post_init__ method and
things will work fine:
class BaseClass:
def __init__(self):
print("class BaseClass")
@dataclass
class DataClass(BaseClass):
def __post_init__(self):
super().__init__()
print("class DataClass")
class ChildClass(DataClass):
def __init__(self):
super().__init__()
print("class ChildClass")
>>> ChildClass()
class BaseClass
class DataClass
class ChildClass
ChildClass()
Note that this will break if you try to add a second dataclass to the
inheritance hierarchy using the same method:
@dataclass
class BrokenClass(ChildClass):
def __post_init__(self):
super().__init__()
>>> BrokenClass()
RecursionError: maximum recursion depth exceeded while calling a Python
object
Maybe some work could be done to allow dataclasses to be smarter about
calling super().__init__() inside of the __post_init__ method (so that
recursion is avoided), I do not know.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
On Tue, Apr 14, 2020 at 7:37 PM Christopher Barker <python...@gmail.com>
wrote:
> On Mon, Apr 13, 2020 at 9:22 PM Neil Girdhar <mistersh...@gmail.com>
> wrote:
>
>> Cool, thanks for doing the relevant research.
>>
>
> For my part, I'd like to see an aeefort to move dataclasses forward. Now
> that they are in the standard library, they do need to remain pretty
> stable, but there's still room for extending them. But it's a bit hard when
> ideas and PRs are mingled in with everything else Python.
>
> Maybe a gitHub repo just for dataclasses?
>
> @Eric V. Smith <e...@trueblade.com>: what do you think? IS there a way to
> keep them moving forward?
>
>
>> I'm just going to swap dataclasses for actual classes whenever I need
>> inheritance. It seems like a pity though.
>>
>
> For my part, I've gotten around it (for a different reason...) with an
> extra inheritance dance:
>
> @dataclass
> MyClassBase:
> ....
>
> MyRealClass(MyClassBase, Some_other_baseclass):
> def __init__(self., args, kwargs):
> dc_args, dc_kwargs = some_magic_with_self.__dataclass_fields__
> MyClassBase.__init__(dc_args, dc_kwargs)
> super().__init__(self, args, kwargs)
>
> and you could put that __init__ in a mixin to re-use it.
>
> Or, frankly, just give your dataclass some extra fields that are needed by
> the superclass you want to use.
>
> -CHB
>
> Best,
>>
>> Neil
>>
>> On Tue, Apr 14, 2020 at 12:07 AM Christopher Barker <python...@gmail.com>
>> wrote:
>>
>>> I feel like it would be nice to be able to use dataclasses more often
>>>> without worrying that you cannot use dataclasses in cooperative
>>>> inheritance. Perhaps, dataclasses could call super with unused args and
>>>> kwargs?
>>>>
>>>
>>> There is a PR on gitHub where a user has requested that dataclasses
>>> (optionally) except any extra kwargs along. I think it saw some support,
>>> but has stalled out. Im pretty sure in that case, the extra kwargs would be
>>> ignored.
>>>
>>> https://github.com/python/cpython/pull/19206
>>> https://bugs.python.org/issue33493
>>>
>>> -CHB
>>>
>>> On Sun, Apr 12, 2020 at 12:49 AM Neil Girdhar <mistersh...@gmail.com>
>>> wrote:
>>>
>>>> class X:
>>>> def __init__(self, x, **kwargs):
>>>> super().__init__(**kwargs)
>>>> print(x, kwargs)
>>>>
>>>>
>>>>
>>>> @dataclass
>>>> class Y(X):
>>>> y: int
>>>>
>>>>
>>>> Y(1) # What should happen?
>>>> Y(1, 2) # What should happen?
>>>>
>>>>
>>>> I feel like it would be nice to be able to use dataclasses more often
>>>> without worrying that you cannot use dataclasses in cooperative
>>>> inheritance. Perhaps, dataclasses could call super with unused args and
>>>> kwargs?
>>>>
>>>> Best,
>>>>
>>>> Neil
>>>> _______________________________________________
>>>> 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/6YMRI4BJDTZZTWM6XQ6EQDZ47RWX4C7C/
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>>
>>>
>>> --
>>> Christopher Barker, PhD
>>>
>>> Python Language Consulting
>>> - Teaching
>>> - Scientific Software Development
>>> - Desktop GUI and Web Development
>>> - wxPython, numpy, scipy, Cython
>>> --
>>> Christopher Barker, PhD
>>>
>>> Python Language Consulting
>>> - Teaching
>>> - Scientific Software Development
>>> - Desktop GUI and Web Development
>>> - wxPython, numpy, scipy, Cython
>>>
>>
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
> _______________________________________________
> 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/WLKKFCNAPYPOVUEHXMJNBNJPAECB7QKR/
> 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/RKQRYH6X75LVTSLD3ZFFGHGIW2BUAMHI/
Code of Conduct: http://python.org/psf/codeofconduct/
