On Fri, 26 Nov 2021 at 09:14, Paul Moore <p.f.mo...@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-...@python.org/thread/SNKJB2U5S74TWGDWVD6FMXOP63WVIGDR/#A5JFR7RDE7NNKESM2DWYM3ZT5ZYGOLCF
[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
_______________________________________________
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/ODJYIGGSHMNS3BZND7UNVROPQ4LPW4R7/
Code of Conduct: http://python.org/psf/codeofconduct/
