typing
typing copied to clipboard
Annotate sync/async code via Generic | generic TypeVar / Type aliases in Generic
Consider this case:
import asyncio
from typing import Any, Coroutine, Generic, TypeVar
from httpx import AsyncClient, Client, Response
ClientT = TypeVar("ClientT", bound=Client | AsyncClient)
class API(Generic[ClientT]):
client: ClientT
def __init__(self, client: ClientT) -> None:
self.client = client
def get_items(self) -> Response | Coroutine[Any, Any, Response]:
return self.client.request('get', 'https://example.com/api/v1/get_items')
response = API[Client](Client()).get_items()
response.json() # Item "Coroutine[Any, Any, Response]" of "Union[Response, Coroutine[Any, Any, Response]]" has no attribute "json" [union-attr]
response_coroutine = API[AsyncClient](AsyncClient()).get_items()
asyncio.run(response_coroutine) # Argument 1 to "run" has incompatible type "Union[Response, Coroutine[Any, Any, Response]]"; expected "Awaitable[Response]" [arg-type]mypy(error)
How can I express bound between ClientT
and return type of API().get_items()
?
How it could look like if Generic
would support type aliases or TypeVar supported another type variables:
import asyncio
from typing import Annotated, Any, Awaitable, Coroutine, Generic, TypeVar
from typing_extensions import reveal_type
from httpx import AsyncClient, Client, Response
ClientT = TypeVar("ClientT", bound=Client | AsyncClient)
T = TypeVar("T")
# Using Annotated just as generic type that returns its argument as is
Sync = Annotated[T, ...]
MightBeAwaitable = TypeVar("MightBeAwaitable", bound=Awaitable | Sync)
# or MightBeAwaitable = Awaitable | Sync
class API(Generic[ClientT, MightBeAwaitable):
client: ClientT
def __init__(self, client: ClientT) -> None:
self.client = client
def get_items(self) -> MightBeAwaitable[Response]: # TypeError: 'TypeVar' object is not subscriptable
return self.client.request('get', 'https://example.com/api/v1/get_items')
response = API[Client, Sync](Client()).get_items()
reveal_type(response) # Revealed type is "Response"
response_coroutine = API[AsyncClient, Awaitable](AsyncClient()).get_items()
reveal_type(response_coroutine) # Revealed type is "typing.Awaitable[Any]"
Sorry if it's the wrong place/type for this issue.
Might be duplicate / use case of #548
Perhaps something like this?
import asyncio
from typing import Any, Coroutine, Generic, TypeVar, overload
from httpx import AsyncClient, Client, Response
ClientT = TypeVar("ClientT", bound=Client | AsyncClient)
class API(Generic[ClientT]):
def __init__(self, client: ClientT) -> None:
self.client = client
@overload
def get_items(self: "API[Client]") -> Response: ...
@overload
def get_items(self: "API[AsyncClient]") -> Coroutine[Any, Any, Response]: ...
def get_items(self) -> Response | Coroutine[Any, Any, Response]:
return self.client.request('get', 'https://example.com/api/v1/get_items')
Interesting. It could work, I'll try it. Thank you!
Though, does it imply that every method needs to be annotated as like thus, or it can be done only for root methods and return annotations for ones that use them can be omitted?
This would have to be done for every method that becomes sync
/async
based on the type of client passed in to __init__
.
Then I'd say its too much of a duplication/overloads that going to obstruct actual code. Writing it in .pyi files will help with readability, but still will make process of writing/changing the code more complicated than it should be.
There really isn't a way to correctly type this without overloads. The solution suggested at the end of the question wouldn't really work, even if HKTs did make it into Python, as it would allow for something like
response = await API[Client, Awaitable](Client()).get_items()
without the type checker complaining. This is equivalent to having a response_type
parameter and passing in Awaitable
or Sync
. It doesn't actually enforce anything.
P.S.: I would also switch Awaitable
for Coroutine
since that is more "correct". If some decorator requires a Coroutine
as return type, it will not accept get_items
methods since Awaitable
is not compatible with Coroutine
, even though the code actually works. Generally, try to be as broad as possible on input types and as precise as possible on output types.