Hi! Thanks for this awesome project!

I am TypedDjango team member, we maintain types for, well, django. And we do pretty much the same job.

For example, we test our types like so: tests/. We even created a tool called pytest-mypy-plugins (announcing post) to help us with this task. Maybe it will be also helpful to you as well.

That's how the simplest test looks like:

- case: compose_two_wrong_functions
  main: |
    from returns.functions import compose

    def first(num: int) -> float:
        return float(num)

    def second(num: float) -> str:
        return str(num)

    reveal_type(compose(first, second)(1))  # N: builtins.str*

Ask any questions you have!

P.S. This project was listed in awesome-python-stubs list.

Hey, thanks a ton for these stubs :)

I have recently added some client implementation to my server code (it's a gRPC server that queries another gRPC server), meaning that it makes use of the client stub of that other server.

Now mypy started complaining about

error: Call to untyped function "ServiceStub" in typed context  [no-untyped-call]

This error is happening on the line in which I instantiate my client:

channel = grpc.insecure_channel("some-address:8000")
client = ServiceStub(channel)  # This line is triggering the error
response = client.SomeMethod(request)

I had a quick look into this repo to check if I was simply missing something, but I did indeed not find any stubs for the client stubs.

Are they missing? Is there a good way for me to get rid of that error other than ignoring it?

Was having issues importing grpc_health stubs.

Example:

from grpc_health.v1.health_pb2 import HealthCheckRequest
from grpc_health.v1.health_pb2_grpc import add_HealthServicer_to_server

All files are generated using mypy-protobuf.

Description

Currently, you are unable to call await on the result of asyncio calls on client stubs. This is because we define our own Future and CallFuture objects, that are not marked as Awaitable -- so mypy thinks they cannot be used with await.

Original problem

I generated some stubs using mypy-protobuf. I also have grpc-stubs==1.24.6 installed.

My stub looks like this:

class FooServiceStub:
   ...
    ListFoo: grpc.UnaryUnaryMultiCallable[
        global___ListFooRequest,
        global___ListFooResponse] = ...

Later, when I try to use this like so:

client = FooServiceStub(...)
req = ListFooRequest()
result = await client.ListFoo(req).future()

However this yields a mypy error: Incompatible types in "await" (actual type "CallFuture[ListFooResponse]", expected type "Awaitable[Any]").

Alternate Solutions

Awaitable could be added to the base Future type instead of to CallFuture.

Hi, thanks for this awesome project, it really helps a lot. As the title say, can mypy be an install dependency? In many scenarios, pyi stubs are used for augmenting Pycharm auto-completement instead of type-check jobs, without installing mypy, tens of megabytes of packages will be reduced from the virtual env.

This attempts to fix some of the asyncio issues by converting metadata to Anys. Not particularly proud of the solution, but may be an OK band-aid in the meantime if it can get things unblocked. All the rest of the code is the original code from https://github.com/shabbyrobe/grpc-stubs/pull/15

The current distribution package doesn't include the py.typed files in this repo. This isn't a blocker, as they aren't strictly required in a stub-only package. However this may be unexpected?

The grpc.aio module has good type annotation, but without these stubs existing mypy falls over when using it whilst the gRPC stubs in this repository are installed.

The stubs themselves are autogenerated with stubgen and tidied up by hand.

All fields in ClientCallDetails are optional except for method. This object encapsulates arguments passed to rpc method calls on client stubs, for which only the request object is required.

Reference: https://github.com/grpc/grpc/blob/master@{2019-12-05}/src/python/grpcio/grpc/_interceptor.py#L227-L234

Description of issue

Problem: Status code "OUT_OF_RANGE" is defined in google.rpc but is not present in grpc-stubs.

Solution: Add + OUT_OF_RANGE = ... to grpc-stubs/__init__.pyi

Minimum Reproducible Example

Mypy fails with no attribute "OUT_OF_RANGE":

The current typehint wants a list of various client interceptors, when in reality it should be a list of ServerInterceptor as per the docs:

interceptors: An optional list of ServerInterceptor objects that observe and optionally manipulate the incoming RPCs before handing them over to handlers. The interceptors are given control in the order they are specified. This is an EXPERIMENTAL API.

Hi, Just curious about a change in the last release (1.24.9)

After this change, I'm finding it hard to set the status of services without a mypy error.

The code straight from the grpc examples https://github.com/grpc/grpc/blob/master/examples/python/xds/server.py:

    # Mark all services as healthy.
    health_pb2_grpc.add_HealthServicer_to_server(health_servicer, server)
    for service in services:
        health_servicer.set(service, health_pb2.HealthCheckResponse.SERVING)

Now causes a mypy error of:

Argument 2 to "set" of "HealthServicer" has incompatible type "ValueType"; expected "ServingStatus"  [arg-type]

I think argument 2 should be a HealthCheckResponse.ServingStatus.ValueType ? Defined in grpc_health-stubs/v1/health.pyi

This never used to cause a problem with health_pb2 stubs missing, but now they are there I am getting this error. Or if I am wrong about that arguments type, how do I now set a servicer status without a mypy error?

Is there any plans to include stubs for grpc.aio? I love this package but it doesn't seem to provide the aio features. I am more than willing to help out if necessary. I also saw a discussion about this in #15, but not sure what's happening here.

Hello 👋. I found this repo and this works really well with mypy. I was wondering if you had any plans of including this in typeshed so that it is automatically included in mypy. I am not sure the exact amount of work needed but it does not sound like a lot. If you do not have the time, I might be able to try to do it as well if you want! Thank you for making this either way!