[issue38758] @dataclass defaults

[Anthony]

Anthony <anthonysarkis at gmail.com> added the comment:

To clarify,
A major assumption I'm making is that the default is empty, or the
"copying" is handled as some separately coupled concept.
A motivation here is wanting to do operations like .append() that depend on
the object existing.

On Wed, Nov 13, 2019 at 1:04 PM Anthony Sarkis <anthonysarkis at gmail.com>
wrote:

> Thanks for adding it, I read it now.
>
> And sorry to back track a moment - I love the idea of @dataclass and I can
> only imagine how must work it was to implement as I am only a beginner.
>
> I'm looking at this primarily from the narrow view point of a user - not
> so much understanding the backdrop of how it can actually work.
> But I still think this is worth considering as I think this is common
> pattern based on this logic:
>
> When using the default construction method it seems reasonable to pass a
> default, such as a List.
> Because
> def __init__(x=[]):
>   self.x = x
> Is the cleanest way I can think of to write that.
> In this new context, if x: list = [] is the cleanest way to write it.
> Therefore it should do that, however it is actually implemented.
>
> Let's imagine for a moment that @dataclass becomes the default way of
> constructing classes in python.
> Do we really want such a common case to require such verbose language?
>
> Looking at Guido's first comment on this, I think that detection mechanism
> is what I would expect to happen. To illustrate verbosely:
> https://gist.github.com/swirlingsand/d59d01ef79c5ee93f430ed324199bc65
> I clearly misunderstood the way classes get passed by default.
> I continue to believe that defining it in the argument should be equal to
> defining it after. (if there are no other context items present).
>
> From a beginners perspective here, It would appear that in a sense the
> default init is actually "silently failing" in that the expected (because
> of the two instances not being equal to each other as shown in L10 above)
> isolation is not happening.
> In a sense then, @dataclass is turning that silent "failure" into a
> ValueError which is actually better.
>
> What about something like this:
> https://gist.github.com/swirlingsand/2494bc482902fada2248698f7b8af61e
> If the common case is for it to be None, then this doesn't fire so there's
> no cost.
> If it's a common default then it handles it as expected.
> If it's not found it raises a ValueError like before, so there's no loss
> or harm.
> A handful of defaults here may cover 80% of cases and the 20% can continue
> to be handled by ValueError
> In a project with 40 classes with 10 defaults per class that's 400 lines
> of code that look like:
> []
> instead of
> field(default_factory=lambda: [])
> (or {} etc.)
>
> Issue #3 has many comments around copying, but that's not my concern, I'm
> just talking about the defaults where the attribute is not provided at all
> (ie is None).
>
> I did the above example in regular python since I don't know enough about
> how @dataclass is implemented, but it seems reasonable that if it can work
> in normal python there should be a way to say augment operation() on line
> 21 with field()
>
>
>
>
>
>
> On Wed, Nov 13, 2019 at 10:11 AM Vedran Čačić <report at bugs.python.org>
> wrote:
>
>>
>> Vedran Čačić <vedgar at gmail.com> added the comment:
>>
>> Have you read https://github.com/ericvsmith/dataclasses/issues/3?
>>
>> ----------
>> nosy: +veky
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <https://bugs.python.org/issue38758>
>> _______________________________________
>>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38758>
_______________________________________