[issue38758] @dataclass defaults

Guido van Rossum added the comment: This should not have been an issue but a discussion on python-list or perhaps python-ideas. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue38758] @dataclass defaults

Anthony added the comment: Vedran thank you for the detailed comments. I want to separate the idea side and implementation: The idea is having defaults expressed in a way of least surprise and in the least amount of code. Specifically that [1] makes more sense then

[issue38758] @dataclass defaults

Raymond Hettinger added the comment: I concur with Vedran and recommend this proposal be rejected. During training and code review, we spend a lot of time trying to get people to not write code like this. By making dataclasses behave differently than the rest of language, we would would

[issue38758] @dataclass defaults

Vedran Čačić added the comment: It seems to me that what you're missing is that "class declarations" are still perfectly normal executable statements (in most other superficially similar programming languages, they are not). So, when you say class A: b = [] it is actually executed, a

[issue38758] @dataclass defaults

Eric V. Smith added the comment: I'm not sure what you're proposing. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38758] @dataclass defaults

Anthony added the comment: Hey Eric, I think our emails crossed in the wind, please see my comment that includes (as a sub component) a similar idea to what's proposed in the article you linked. -- ___ Python tracker

[issue38758] @dataclass defaults

Eric V. Smith added the comment: The problem is that what you wrote isn't what most people want. Here's your example without dataclasses. I've added an "append_to_x" method, which does the obvious thing: >>> class C: ... def __init__(self, x=[]): ... self.x = x ... ... def

[issue38758] @dataclass defaults

Anthony 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

[issue38758] @dataclass defaults

Anthony added the comment: 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

[issue38758] @dataclass defaults

Vedran Čačić added the comment: Have you read https://github.com/ericvsmith/dataclasses/issues/3? -- nosy: +veky ___ Python tracker ___

[issue38758] @dataclass defaults

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38758] @dataclass defaults

New submission from Anthony : Given one of the motivations of @dataclass is to reduce boilerplate code then, in the context of @dataclass, x: list = [] should be equal to x: list = field(default_factory=lambda: []) The example in PEP 557 is not reasonable. It should be: class D: def