On Tue, 2021-04-13 at 11:33 +0900, Inada Naoki wrote: > On Tue, Apr 13, 2021 at 11:18 AM Paul Bryan <pbr...@anode.ca> wrote: > > > > On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote: > > > > On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings <la...@hastings.org> > > 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. Paul
_______________________________________________ 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/HJNS3JHQNZ3WFG44PXTNLFLJTQRYJWCS/ Code of Conduct: http://python.org/psf/codeofconduct/
