I'm a big fan of this PEP, for many reasons. But the fact that it addresses some of the issues with get_type_hints() is very important. dataclasses avoids calling get_type_hints() for performance reasons and because it doesn't always succeed, see https://github.com/python/typing/issues/508. I believe this issue is fixed by PEP 649.
On 4/12/2021 2:34 AM, Larry Hastings wrote:
On 4/11/21 7:55 PM, Paul Bryan wrote:
I recognize the point you make later about its impact on static type checkers. Setting that aside, I'm wondering about caes where annotations can be dynamically generated, such as dataclasses.make_dataclass(...). And, I could see reasons for overwriting values in __annotations__, especially in the case where it may be stored as a string and one wants to later affix its evaluated value. These are considerations specific to runtime (dynamic) type checking.
It's fine to modify the __annotations__ dict after the creation of the class or module. It's code that modifies "__annotations__" from within the class or module that is disallowed here. Similarly for dataclasses; once it creates a class object, it can explicitly set and / or modify the annotations dict on that class.
There won't be any direct impact to make_dataclass(). It doesn't do anything tricky here: it just builds up the annotations dictionary and passes it as __annotations__ to the class namespace in types.new_class(). After creating the class, it just applies the normal dataclass() decorator.