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.
Eric
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/T4KPZKA57SPV2JQPEVZLYMPF45F2TFSG/
Code of Conduct: http://python.org/psf/codeofconduct/
