On 4/14/2020 7:34 PM, Christopher Barker 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 think it's fine to make suggestions and have discussions here. Dataclasses aren't sufficiently large that they need their own repo (like tulip did, for example).

But I also don't think we're going to just add lots of features to dataclasses. They're meant to be lean. I realize drawing the line is difficult. For example, I think asdict and astuple were mistakes, and should have been done outside of the stdlib.

 
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.

I think the suggestion elsewhere of InitVarArgs and InitVarKwargs might have some merit, although I think getting input from mypy or some other type checkers first would be a good idea.

Eric

-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/