Yes, asynczip() sounds like a nice abstraction if you already have two async-iterable streams.
Perhaps it makes sense to add it to aiohttp, or to release it as a separate PyPI package first. On Tue, Apr 19, 2016 at 8:53 AM, Julien Palard <jul...@palard.fr> wrote: > o/ > > On 04/18/2016 05:31 PM, Guido van Rossum wrote: > > You can do this using callbacks, or you can have separate loops > > You're right, look like I forgot to drop some context: my aggregation of > various asynchronous iterables should happen within a `def` (when this > `def` returns, the connection is closed, I'm using aiohttp). > > So, from my point of view, the following design looked obvious: > > async def request_handler(self, request): > async for message in asynczip(request.messages, > *self.event_sources): > if message_is_from_client(message) and message['data'] == > 'close': > return > request.socket.send(message) > > Like you said, I can use a shared state object and callbacks, maybe like: > > async def request_handler(self, request): > for source in self.event_sources: > source.on_message(request.socket.send) > async for message in request.messages: > if message['data'] == 'close: > return > > It does not look that wrong, in one hand, it clearly separates messages > from server and messages from client, which was badly merged in the > asynczip. In the other hand, I have to unsubscribe my callbacks or maybe > use weak references to avoid writing to a closed socket. > > I think asyncio is a great and nice abstraction of callbacks, which I > don't like. It's obviously right that we can replace "asynczip" (I don't > like the name) with callbacks, but it probably make the code less > readable, less "asyncio", and also, due to various references, more > "tangled" and bug prone (just a personal intuition). > > I'll probably take the time to implement my project without asynczip, > with just callbacks to have a real diff to look at. > > > -- > Julien Palard > -- --Guido van Rossum (python.org/~guido)
