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

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
_______________________________________________
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/SSG2VXIMBQI5FC5S3G72GQ3XQTL6RSWS/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to