On Wed, Apr 20, 2022 at 3:31 PM Pablo Alcain <pabloalcain@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 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. -Josh