On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote:
This is really the heart of the debate over PEP 649 vs PEP 563. If you examine an annotation, and it references an undefined symbol, should that throw an error? There is definitely a contingent of people who say "no, that's inconvenient for us". I think it should raise an error. Again from the Zen: "Special cases aren't special enough to break the rules." Annotations are expressions, and if evaluating an expression fails because of an undefined name, it should raise a NameError.
I agree that this is the heart of the debate. I think "annotations are
for type hitns". They are for:
* Static type checkers
* document.
+ dynamic type validation, encoding and decoding (Pydantic, FastAPI, Fondat, et al.)
Paul
OK. It is important use case too.
Such use cases doesn't justify raising NameError instead of getting
stringified type hints for documents for document use cases.
On the other hand, if "dynamic type" is used heavily, eval()
performance can be a problem.
In 3.9 this cost is paid once when a type is defined. However, in 3.10, it gets expensive, because when the string is evaluated by get_type_hints, its result is not stored/cached anywhere (repeated calls to get_type_hints results in repeated evaluation). As a workaround, I have code to "affix" the evaluated expression in __annotations__ value. PEP 649 would resolve this and eliminate the need for such a hack.