[Python-Dev] PEP 557: Data Classes
Eric V. Smith
eric at trueblade.com
Sun Sep 10 21:20:31 EDT 2017
> On Sep 10, 2017, at 5:13 PM, Mike Miller <python-dev at mgmiller.net> wrote:
> Thanks for the info.
> On 2017-09-08 15:40, Eric V. Smith wrote:
>>> - Are types required?
>> Annotations are required, the typing module is not.
>>> Maybe an example or two with Any?
>> I'd rather leave it like it is: typing is referenced only once, for ClassVar.
> Guess I really meant "object" or "type" above, not "typing.Any."
> For a decade or two, my use of structs/records in Python has been dynamically-typed and that hasn't been an issue. As the problem this PEP is solving is orthogonal to typing improvements, it feels a bit like typing is being coupled and pushed with it, whether wanted or not.
> Not that I dislike typing mind you (appreciated on projects with large teams), it's just as mentioned not related to the problem of class definition verbosity or lacking functionality.
Using type annotations buys two things.
One is the concise syntax: it's how the decorator finds the fields. In the simple case, it's what let's you define a data class without using the call to fields(), which is analogous to attrs's attr.ib().
The other thing it buys you is compatibility with type checkers. As Ivan said, the design was very careful to be compatible with type checkers.
So other than requiring some type as an annotation, there's no dependency added for typing in the genera sense. You can use a type of object if you want, or just lie to it and say None (though I'm not recommending that!). It's completely ignored at runtime (except for the ClassVar case, as the PEP states).
I'll think about adding some more language to the PEP about it.
More information about the Python-Dev