On Thu, Apr 21, 2022 at 7:33 PM Josh Rosenberg < shadowranger+pythonid...@gmail.com> wrote:
> > On Wed, Apr 20, 2022 at 3:31 PM Pablo Alcain <pabloalc...@gmail.com> > wrote: > >> >> About dataclasses, the point that Chris mentions, I think that they are >> in a different scope from this, since they do much more stuff. But, beyond >> this, a solution on the dataclass style would face a similar scenario: >> since the `__init__` is autogenerated, you would also be in a tight spot in >> the situation of "how would I bind only one of the items?". Again, now I'm >> talking about my experience, but I think that it's very hard to think that >> we could replace "classes" with "dataclasses" altogether. Here's an example >> of one of the (unexpected for me) things that happen when you try to do >> inheritance on dataclasses: https://peps.python.org/pep-0557/#inheritance >> . >> >> dataclasses, by default, do four things with the annotated fields defined > in the class: > > 1. Generate a __init__ > 2. Generate a reasonable __repr__ > 3. Generate a reasonable __eq__ > 4. Automatically support destructuring with match statements > This is very interesting. I use dataclasses quite a lot tbh, but I do think that the purpose is different: the `__repr__` and `__eq__` they generate, for example, are reasonable when you consider that the classes are "mutable namedtuples with defaults". the effective use of dataclasses indeed goes beyond the "mutable namedtuples" thing, but as this happens then the "reasonability" of the default `__repr__` and `__eq__` also starts to fade. as a small experience token: in one point in time, I ended up having a `dataclass` that reimplemented both `__init__` (through `__post_init__`) and `__repr__`. Then I realized that I probably didn't want a dataclass to begin with. > > > And you can independently disable any/all of them with arguments to the > decorator. They *can* do much more, but I find it pretty unusual to *ever* > write a class that I wouldn't want most of those for. The __init__ it > generates is essentially automatically writing the boilerplate you're > trying to avoid, so it seems entirely reasonable to consider this the same > scope. > > As for "how would I bind only one/some of the items?", dataclasses already > support this with dataclasses.InitVar and a custom __post_init__ method; so: > > class MyClass: > > def __init__(self, @a, @b, c): > > ... do something with c that doesn't just assign it as self.c... > > where you directly move values from the a and b arguments to self.a and > self.b, but use c for some other purpose, is spelled (using typing.Any as a > placeholder annotation when there's no better annotation to use): > > @dataclass > class MyClass: > a: Any > b: Any > c: InitVar[Any] > def __post_init__(self, c): > ... do something with c that doesn't just assign it as self.c; > self.a and self.b already exist ... > > The only name repeated is c (because you're not doing trivial assignment > with it), and it's perfectly readable. I'm really not seeing how this is > such an unwieldy solution that it's worth adding dedicated syntax to avoid > a pretty trivial level of boilerplate that is already avoidable with > dataclasses anyway. > I think that in some scenarios it can be done, but it doesn't look very clean: namely with the explicit declaration of `InitVar` and the usage of the `__post_init__`. It looks like this case in which you don't like the autogenerated solution and patch it to reflect your actual goal. It's ok, but it's also going to lead towards harder to mantain and interpret code. > > -Josh > Overall, I think that not all Classes can be thought of as Dataclasses and, even though dataclasses solutions have their merits, they probably cannot be extended to most of the other classes. Pablo
_______________________________________________ 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/B6Q4LFCETYYY6HOR7UT4ZC5MQ73SJ3YA/ Code of Conduct: http://python.org/psf/codeofconduct/
