On 2017-12-21 22:45, Chris Barker wrote:
> On Thu, Dec 21, 2017 at 11:55 AM, Terry Reedy <tjreedy at udel.edu> <mailto:tjreedy at 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
> 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....
>
