These are chat archives for evhub/coconut

10th
Jul 2016
Constantine Molchanov
@moigagoo
Jul 10 2016 18:39

@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 asyncio_map with 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.

Evan Hubinger
@evhub
Jul 10 2016 23:56
@moigagoo Alright, that use case for an async_map makes 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 parallelize would have to only take map objects, which I think would be more confusing than just having it attached to map.