Thanks. Concern allayed. 🙂 On Thu, 2020-12-10 at 21:55 -0800, Guido van Rossum wrote: > 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/ > >
_______________________________________________ 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/NJUTIIV4XHGOJCMKDWW4NGDHKVZ7DQGZ/ Code of Conduct: http://python.org/psf/codeofconduct/
