Hi Paul, The runtime component is the API provided by the `typing` module such as `get_type_hints()`, plus the `__annotations__` attribute on various objects (classes and functions, mostly).
I am not aware of any plans or proposals to remove `__annotations__` or `typing.get_type_hints()`, and obviously use cases like yours abound. That said, the needs of static checking (e.g. mypy) and runtime checking (e.g. JSON schema checkers) sometimes diverge, and in those cases I tend to favor the needs of static checkers. PEP 563 is an example: we found that developers were having a hard time with the original requirement that all annotations are evaluated as expressions at the time the function definition is executed, since it makes forward references difficult (requiring the hack of enclosing the annotation in string quotes). At the same time we found that static type checks are much more used than runtime type checks -- presumably for performance reasons. So PEP 563 was born -- annotations containing forward references no longer need to be quoted, making the use of static checkers simpler, while still catering to the needs of runtime checkers via typing.get_type_hints(). (Note that the latter was already needed to deal with explicitly quoted forward references pre-PEP-563.) It is not inconceivable that eventually type system features will be introduced that are hard to check at runtime, and in such cases we will not let that stop us from defining the new type system feature. (I already doubt that there are runtime checkers that check the consistent use of type variables at runtime.) That said, I don't see a reason to start deprecating the runtime introspection features of the existing annotation syntax, and if you look at PEP 585 (`list[int]` etc.) or PEP 604 (`int | str` union notation) you'll see that they are completely runtime introspectable. (Believe me, it would have been much simpler to erase type parameters completely at runtime, but I personally wrote most of the implementation to make them available via attributes on the `types.GenericAlias` type.) Hope this helps, --Guido On Thu, Dec 10, 2020 at 7:17 PM Paul Bryan <pbr...@anode.ca> wrote: > Per PEP 563: > > Most importantly, Guido van Rossum explicitly stated interest in gradually > restricting the use of annotations to static typing (with an optional > runtime component). > > > As I'm working on runtime type encoding and validation using type > annotations, this passage raises a bit of a concern, as I don't know what > is meant by optional runtime component. > > Looking for any discussion on this. I checked: > > https://bugs.python.org/issue38605 > https://github.com/ambv/static-annotations/issues?q=is%3Aissue+is%3Aclosed > > Can't find any references to runtime. Can someone point me to (or briefly > explain) the thinking on this? > > Thanks, > > 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/FZC6LSXUMX4I7MV5TYUXV76KATOYWGPZ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/OSA7VKZSAHQTTVEJDU2MZXESQKTDNKTB/ Code of Conduct: http://python.org/psf/codeofconduct/
