This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients eric.smith, gvanrossum, levkivskyi
Date 2018-01-03.22:06:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1515017213.43.0.467229070634.issue32428@psf.upfronthosting.co.za>
In-reply-to
Content
> > 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 PEP 526 which requires class variables to be annotated with ClassVar[...]. On the other hand some people may be unhappy that they need to import `typing` to define a class variable in a dataclass. So this is a convenience vs consistence question. I am more in favour of consistence here, but only +0.

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 the current spec of PEP 557 (which lets you omit ClassVar), except for this special case:

> 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).

Agreed. That's a special case and I'm fine with flagging it as an error.
History
Date User Action Args
2018-01-03 22:06:53gvanrossumsetrecipients: + gvanrossum, eric.smith, levkivskyi
2018-01-03 22:06:53gvanrossumsetmessageid: <1515017213.43.0.467229070634.issue32428@psf.upfronthosting.co.za>
2018-01-03 22:06:53gvanrossumlinkissue32428 messages
2018-01-03 22:06:53gvanrossumcreate