These are chat archives for evhub/coconut
@evhub That's a great question. I'm trying to think about the usecases for it. There's a picture in my head, something I wish would be doable with Coconut:
listen_for_requests() |> asyncio_map$(handle_request).
listen_for_requests is an async def that would yield incoming requests, and
handle_request is a handler called for each request asynchronously. So, this would be the easiest async server—something that's not so fancy with plain Python. Turning this server into a thread-based one would mean just replacing
concurrent_map. That's my vision and it may be absolute dog sh*t, but that's how I'd love to see the future :-)
Also, I've been thinking about whether it'd be possible to decouple parallel, concurrent, asyncio from map, e.g. do something like this:
iterator |> map$(handle_element) |> parallelize instead of
iterator |> parallal_map$(handle_element). Again, this may make no sense at all.
async_mapmakes sense to me. I opened an issue for it (#124). I'm uncertain about separating out
parallelize, though, since the parallelization is part of the implementation of map--there's no good way to parallelize an arbitrary iterator, thus
parallelizewould have to only take
mapobjects, which I think would be more confusing than just having it attached to