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 <pythonchb@gmail.com> wrote:
On Mon, Apr 13, 2020 at 9:22 PM Neil Girdhar <mistersheik@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: 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 <pythonchb@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.


-CHB

On Sun, Apr 12, 2020 at 12:49 AM Neil Girdhar <mistersheik@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-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/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-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/WLKKFCNAPYPOVUEHXMJNBNJPAECB7QKR/
Code of Conduct: http://python.org/psf/codeofconduct/