On Tue, Apr 14, 2020 at 7:46 PM Ricky Teachey ricky@teachey.org wrote:
For simple situations you can call super in the __post_init__ method and things will work fine:
But not for the OP's case: he wanted to pass extra parameters in -- and the dataclass' __init__ won't accept extra arguments.
-CHB
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 eric@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 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.
https://github.com/python/cpython/pull/19206 https://bugs.python.org/issue33493
-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/6YMRI4... 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/WLKKFC... Code of Conduct: http://python.org/psf/codeofconduct/