On Thu, Oct 21, 2021 at 5:24 PM Steven D'Aprano <st...@pearwood.info> wrote:
> Runtime type checkers already have to deal with forward refs that are > strings, as this is legal, and always will be: > > def function(arg:'Spam') -> Any: ... > > so we're not putting any extra burden on them. And we had already > agreed to implicitly use strings for annotations. > I'll take your word for it. However, other runtime uses for annotations may not already need to support strings as types. Pydantic is the classic example. I'm not entirely sure how it does its thing, but I have code built on dataclasses that is likely similar -- it expects the annotation to be an actual type object -- an actual class, one that can be instantiated, not even the types that are in the typing module, and certainly not a string that needs to be evaluated. So having them sometimes, maybe sometimes be strings would be a big pain in the @$$ On the other hand, having them be some odd "ForwardReference" type, rather than a NameError might be OK -- as long as SOME exception was raised as soon as I tried to use it. Though it would make for far more confusing error messages :-( My first choice would be to get a NameError at module load time, like we do now. Second would be a NameError as soon as it is accessed. Getting a special value is OK though, now that I'm thinking about it, I could probably put that special case code in one place, and provide a nice error message. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/WAE5LTKPBCEEBPR3ZHRGWJEGIEQ6RI6G/ Code of Conduct: http://python.org/psf/codeofconduct/
