
On Fri, 26 Nov 2021 at 09:14, Paul Moore <p.f.moore@gmail.com> wrote:
I'd therefore interpret Barry's plea as being for *anyone* with a use for annotations to provide their feedback (at least, anyone who accepts that annotations are types), with particular emphasis on people who want to use the types declared in annotations to affect runtime behaviour, as that's the most under-represented group at the moment (and it's not clear whether it's under-represented because there aren't many such uses, or because the users aren't being heard from).
I don't know if this helps, but I'm a maintainer/creator of a Python library that uses type annotations at runtime. The library is used to create GraphQL APIs[1]. We took a lot of inspiration from dataclasses, our API looks like this: ```python @strawberry.type class User: name: str ``` The `strawberry.type` decorator reads the annotations and creates an object with a list of fields and types, but it doesn't try to resolve them (that happens later to prevent issues with circular dependencies and so on). I remember the discussion around PEP 563 and how it would break libraries using type annotations, in our case things are fine since the types we define should be defined in the global namespace[2] anyway. I think the only issue we have with type annotations is when you have circular references inside your python code (where you'd use `if TYPE_CHECKING: import X`), we "solved" that with a custom class called `LazyType[type, module]`, that allows to specify a type and where it comes from, so our library can resolve the proper type, even if it was not imported in the namespace of the class using that type. Sorry for the digression into some of the details of how the library works, I hope it helps a bit understanding the use case. I think there's definitely use cases for type hints being used at runtime. I personally love the fact that we are allowed to do this, in other languages (like TypeScript) you don't have access to the types at runtime and it does prevent the creation of libraries like dataclasses or mine, which is a bit of a shame (you'd need to use code generation to get a similar experience). There's also other libraries that use type hints at runtime (not for runtime type validation[3]): - Typer - http://typer.tiangolo.com - SQLModel - http://sqlmodel.tiangolo.com - Beanie - https://github.com/roman-right/beanie/ - Pydantic - http://pydantic-docs.helpmanual.io - odmantic - https://github.com/art049/odmantic/ - singledispatch - https://docs.python.org/3/library/functools.html#functools.singledispatch [1] If you're not familiar with GraphQL there's some info here: https://graphql.org [2] I did ask if there was a way to resolve types when having them encapsulated into functions, but that was a specific use case with tests and I was/am fine with using global there https://mail.python.org/archives/list/typing-sig@python.org/thread/SNKJB2U5S... [3] while I see runtime validation being something useful, I think it is worth taking a look at different use cases for type hints :) -- Patrick Arminio