![](https://secure.gravatar.com/avatar/7c8980f8e355f6579688a1535899fb9e.jpg?s=120&d=mm&r=g)
I've been adding pyi dataclass and attr declarations to pytype, and I've spent the last month trying to track down edge cases that pytype should support. In particular, this part of your proposal differs from dataclass behaviour: @dataclass class Employee: # Field with no descriptor name: str # Field that uses field descriptor class instance age: Optional[int] = field(default=None, init=False) # Field with type annotation and simple initializer to # describe default value is_paid_hourly: bool = True # Field with inferred type and simple initializer to # describe default value office_number = "unassigned" office_number will be a classvar rather than a field, since it's not annotated with a type. Another thing to address is whether the entire range of dataclass field constructors, e.g. InitVars, will be supported in pyi files (initvars in particular would need something like field_descriptors to specify the generic class used to mark an initvar, unless we just say that dataclasses are in the stdlib and other libraries should just use dataclasses.InitVar). martin On Sat, Apr 24, 2021 at 11:10 PM Eric Traut <eric@traut.com> wrote:
Guido, thanks for the feedback. I've updated the spec to incorporate your suggestions.
Yes, I'm recommending that we fix the names of the various allowable keyword parameters. The popular libraries use these parameter names, and I don't see a need to provide additional flexibility here. Of course, we could add more configurability if there's a need, but I'd prefer to keep it simple.
-Eric
-- Eric Traut Contributor to Pyright & Pylance Microsoft Corp. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mdemello@google.com