On Tue, Apr 14, 2020 at 7:46 PM Ricky Teachey <[email protected]> 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 <[email protected]>
> wrote:
>
>> On Mon, Apr 13, 2020 at 9:22 PM Neil Girdhar <[email protected]>
>> 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 <[email protected]>: 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 <[email protected]>
>>> 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 <[email protected]>
>>>> 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 -- [email protected]
>>>>> To unsubscribe send an email to [email protected]
>>>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>>>> Message archived at
>>>>> https://mail.python.org/archives/list/[email protected]/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 -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/[email protected]/message/WLKKFCNAPYPOVUEHXMJNBNJPAECB7QKR/
>> 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
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/RF776G564FI4GPGYAOXG5DUHY6WVA6WX/
Code of Conduct: http://python.org/psf/codeofconduct/
