[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Eric V. Smith added the comment: Correct. I'm working on that one now. I'll open it tonight or tomorrow. -- ___ Python tracker ___

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi added the comment: @Eric > I'm closing this, and will open another issue to raise an error for: ... I think we also need a separate issue for not overriding __repr__ etc, if '__repr__' in cls.__dict__. -- ___

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Eric V. Smith added the comment: I'm closing this, and will open another issue to raise an error for: @dataclass class C: x = field() -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi added the comment: > There is no real conflict with PEP 526 though. PEP 526 introduces ClassVar so > the type checker can be made to understand. PEP 557 allows omitting ClassVar > in case you don't care about type checkers. So I think we should stick with

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Guido van Rossum added the comment: > > I liked the original design better, where things without annotations would > > just be ignored. What changed? > With the original proposal the ignored variables without annotations will > behave as class variables. This "conflicts"

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi added the comment: Just to clarify the previous comment, I still think that flagging this @dataclass class C: x = field() is important, since simply ignoring a ``field()`` will be too confusing (especially for ``attrs`` users). The previous comment

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi added the comment: > I liked the original design better, where things without annotations would > just be ignored. What changed? With the original proposal the ignored variables without annotations will behave as class variables. This "conflicts" with

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Guido van Rossum added the comment: I liked the original design better, where things without annotations would just be ignored. What changed? On Dec 27, 2017 5:19 PM, "Ivan Levkivskyi" wrote: > > Ivan Levkivskyi added the

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi added the comment: > I'm not sure I understand the distinction. Initially I thought about only flagging code like this: @dataclass class C: x = field() But not this: @dataclass class C: x = 42 Now I think we should probably flag both as errors.

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Eric V. Smith added the comment: I'm not sure I understand the distinction. You have to look through everything in `__dict__`, then exclude those things that are any type of field (so, real fields or pseudo-fields). Those are the things that are in `__annotations__`,

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

Ivan Levkivskyi added the comment: A possible question here is should we give an error for any non-callable name in `__dict__` which is not in `__annotations__` or only for `Field`s? After some thinking I am actually leaning towards the first option. -- nosy:

[issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass

New submission from Eric V. Smith : For this class: @dataclass class C: x: int = 0 y = 0 Generate a TypeError. 'y' is not a field (as defined by @dataclass). It should either be a regular field (by giving it a type annotation) or a ClassVar field. --