trio_report.md

trio_report.md

Hello there, I just disovered the existence of Trio today and I was wondering how to gather results from tasks ran concurrently.
I want to do something similar to what asyncio does here:
async def child(x):
    print(f"Child sleeping {x}")
    await asyncio.sleep(x)
    return 2*x

async def parent():
    tasks = [child(t) for t in range(3)]
    return await asyncio.gather(*tasks)

print("results:", await parent())
I found an answer on stackoverflow that suggests something that more or less look like this:
async def gather(tasks):
    results = {}
    async with trio.open_nursery() as nursery:
        for index, task in enumerate(tasks):
            nursery.start_soon(collect, index, task, results)
    return [results[i] for i in range(len(tasks))]

async def collect(index, task, results):
    task_func, *task_args = task
    results[index] = await task_func(*task_args)

async def child(x):
    print(f"Child sleeping {x}")
    await trio.sleep(x)
    return 2*x

async def parent():
    tasks = [(child, t) for t in range(3)]
    return await gather(tasks)

print("results:", await parent())
But that seems odd to me, is that the right way to do this?

Joshua Oreman @oremanj 08:00
Yep, that’s currently the appropriate option — stick that gather() and collect() in some utilities module and forget about the internal weirdness, I’d suggest. :-) (you could even make collect() a local function inside gather())
We do plan to expose this sort of functionality (and more!) in a library soon, just haven’t worked out the full set of details yet

Christian glacet @cglacet 08:05
Ok ok, I just was curious about this. I wont really use this as I need more functionalities (for example handling exceptions, like return_exceptions in asyncio.gather). From the outside it's a bit hard to tell, are there a lot of things missing in Trio that you know you'll work on? (I mean, do you have a rough idea on a potential release date?)
Is there a reason why coroutines aren't used directly in Trio? (why is nursery.start_soon taking a function + arguments as parameters insted of the coroutine?)

Joshua Oreman @oremanj 09:57
I mean, return_exceptions handling is just another few lines of code :-)
There are lots of things we'd like to make better about Trio (https://github.com/python-trio/trio/issues, https://trio.discourse.group/t/priorities-roadmap/34/17 ) but since development happens in volunteers' spare time we try not to make promises about when particular features are going to arrive
@cglacet ^
why is nursery.start_soon taking a function + arguments as parameters insted of the coroutine?
Trio treats coroutine objects as an internal implementation detail that we don't want our users to have to worry about. That is, if foo is an async function, we want people to be able to successfully treat await foo(...) as a single piece of syntax, without needing to think about foo(...) also being valid syntax that doesn't do what it looks like it should do.

Joshua Oreman @oremanj 10:04
As a side benefit, the start_soon interface lets people write fancier supervisors that adhere to the nursery interface, e.g. restarting failed tasks or whatever, because you can run a function specified as func, *args as many time as you want but you can only await a coroutine func(*args) once.

Ronny Pfannschmidt @RonnyPfannschmidt 10:23
@njsmith are there any utilities in trio upcoming to ease specifying protocol parsers/statemachines in a decoupled/testable way (going more declarative)

Christian glacet @cglacet 10:25
@oremanj That makes sense indeed

Nathaniel J. Smith @njsmith 12:06
@RonnyPfannschmidt we have a plan, or at least, vague goal, of encouraging folks to write sans-io state machines and then attach them to trio
There's discussion here: python-trio/trio#796
We would also like to make protocol implementations more testable in general, for example: python-trio/trio#170
_