On 4/14/2020 7:34 PM, Christopher Barker wrote:
On Mon, Apr 13, 2020 at 9:22 PM Neil Girdhar <mistersh...@gmail.com
<mailto: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 <mailto:e...@trueblade.com>: 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
<python...@gmail.com <mailto: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 <mailto: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
<mailto:python-ideas@python.org>
To unsubscribe send an email to
python-ideas-le...@python.org
<mailto: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/V6KQ56VYOR3ZLXZNBGCRD2N3OIDQBJUN/
Code of Conduct: http://python.org/psf/codeofconduct/
