On Thu, Dec 21, 2017 at 3:10 PM MRAB <pyt...@mrabarnett.plus.com> wrote:
> On 2017-12-21 22:45, Chris Barker wrote: > > On Thu, Dec 21, 2017 at 11:55 AM, Terry Reedy <tjre...@udel.edu > > <mailto:tjre...@udel.edu>> wrote: > > > > I think the understanding problem with this feature arises from two > > factors: using annotations to define possibly un-initialized slots > > is non-obvious; a new use of annotations for something other than > > static typing is a bit of a reversal of the recent pronouncement > > 'annotations should only be used for static typing'. > > > > > > you know, that may be where part of my confusion came from -- all the > > talk lately has been about "type hints" and "type annotations" -- the > > idea of "arbitrary annotations" has been lost. > > > > Therefore, getting the permanent doc 'right' is important. > > > > > > yup. > > > > @dataclass > > class C: > > x > > y = 0 > > > > I think the doc should explicitly say that uninitialized fields > > require annotation with something (anything, not necessarily a type) > > simply to avoid NameError during class creation. > > > > > > would this be possible? > > > > @dataclass > > class C: > > x: > > y: = 0 > > > > That is -- the colon indicates an annotation, but in this case, it's a > > "nothing" annotation. > > > > > "..." or "pass", perhaps? > > @dataclass > class C: > x: ... > y: ... = 0 > > or: > > @dataclass > class C: > x: pass > y: pass = 0 > pass does not currently parse in that context. Otherwise I was thinking the same thing. But we already have ... which does - so I'd suggest that for people who are averse to importing anything from typing and using the also quite readable Any. (ie: document this as the expected practice with both having the same meaning) While I consider the annotation to be a good feature of data classes, it seems worth documenting that people not running a type analyzer should avoid declaring a type. A worse thing than no-type being specified is a wrong type being specified. That appearing in a library will break people who need their code to pass the analyzer and pytype, mypy, et. al. could be forced to implement a typeshed.pypi of sorts containing blacklists of known bad annotations in public libraries and/or actually correct type specification overrides for them. As for problems with order, if we were to accept @dataclass class Spam: beans = True ham: bool style instead, would it be objectionable to require keyword arguments only for dataclass __init__ methods? That'd get rid of the need to care about order. (but would annoy people with small 2-3 element data classes... so I'm assuming this idea is already rejected) -gps > > > It's a syntax error now, but would it be possible to change that? Or > > would the parsing be ambiguous? particularly in other contexts. > > > > of course, then we'd need something to store in as a "nothing" > > annotation -- empty string? None? (but None might mean something) create > > yet anther type for "nothing_annotation" > > > > Hmm, I may have talked myself out of it.... > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/greg%40krypto.org >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com