We need to fix the API for 1.0 release. Unfortunately, there are going to be some breaking changes ;)
Here are some of them:
stream_stream client call (and maybe stream_unary) should really be an async context manager: there is implicit thread of execution running that's feeding the internal send buffer with data from async iterable. If the exception occurs when sending the data (e.g. server expects 3 messages, but client sends 4), this exception should not be discarded. This is in contrast to Google's official grpc implementation, which in the example above will silently discard the exception. I do not think this is reasonable.
4: I think I am going to make optional request argument mandatory context argument.
Need to expose stream-like API for those, who does not need separate execution thread for stream_stream calls, this may break something, but I am not sure.
Maybe we should change generated files suffix from _grpc.py to something more self-describing, like _purerpc.py
Overall, I think the API should be as close as it can get to grpcio modulo the corner cases described above.
We need to fix the API for 1.0 release. Unfortunately, there are going to be some breaking changes ;) Here are some of them:
4: I think I am going to make optional
requestargument mandatorycontextargument._grpc.pyto something more self-describing, like_purerpc.pyOverall, I think the API should be as close as it can get to grpcio modulo the corner cases described above.