[Aio] Accepts normal iterable of request messages#22580
[Aio] Accepts normal iterable of request messages#22580lidizheng merged 3 commits intogrpc:masterfrom
Conversation
lidizheng
added
lang/Python
release notes: yes
| ChannelArgumentType = Sequence[Tuple[str, Any]] | ||
| EOFType = type(EOF) | ||
| DoneCallbackType = Callable[[Any], None] | ||
| RequestIterableType = Union[Iterable[Any], AsyncIterable[Any]] |
There was a problem hiding this comment.
Looks like a good solution. 👍
| if inspect.isasyncgen(request_iterator): | ||
| async for request in request_iterator: | ||
| await self._write(request) | ||
| await self._done_writing() |
There was a problem hiding this comment.
Nit: await self._done_writing() is common to both branches.
| # Prepares the request | ||
| payload = messages_pb2.Payload(body=b'\0' * _REQUEST_PAYLOAD_SIZE) | ||
| request = messages_pb2.StreamingInputCallRequest(payload=payload) | ||
| requests = [request] * _NUM_STREAM_RESPONSES |
There was a problem hiding this comment.
Very nice. I can especially see this coming in handy for unit tests.
|
Thanks for the change, out of curiosity and with regards of your points:
I guess that the same as a coroutine, a coroutine does not provide either a good API, and its sufficient when the core is instantiated and executed within the scope of a task. If you want to run it separately you have to wrap the coro into a I would expect the same for the async generator.
Your proposal would be having an |
|
For the first point, as you mentioned, the async generator API will be much better if there is a For the second point, |
3 participants
To improve the usability of our library, this PR enables stream-unary and stream-stream RPCs to accept normal iterable of request messages, instead of only allowing async iterable. So, it is backward compatible.
We was in favor of using async generator and trying to publicize it. However, there are several issues with it:
asyncio.Task(no cancel(), done(), cancelled(), etc.);aiter(...)built-in function (I don't understand CPython team);Also, accepting iterables makes non-complex logic much easier (see example).