Matthias Urlichs

> I don't follow your meaning. Tasks are functions. Writing a task = writing a function. A task is a function with some arguments that you start at a specific...

> By default, a nursery should do the simplest thing, which is to simply sequentially store for them for access after the nursery exits. Which sequence – task start or...

>> Which sequence – task start or task exit? > Considering that the former is nonsensical (saving a value that doesn't exist yet), the latter. What's nonsensical about that? When...

I'm with @njsmith here (and also wearing my DD hat, even if it's kindof rarely used these days): by the time the next Debian release freeze looms Trio should be...

Thank you. Might you be persuaded to also package anyio?

I have to admit that I habitually write sync wrappers to async functions. Semantically there's nothing whatsoever wrong with ``` async def _foo(n: float): await trio.sleep(n) def foo(): return _foo(42)...

These codecov results seem rather spurious.

Isn't it fairly trivial to cross call from one Trio thread to the other? `await trio.to_thread(functools.partial(trio.from_thread.run, fn, *args, trio_token=other_task.token))` If you don't want the overhead, well, creating something like `trio._threads.cross_thread.run(fn,...

Dropping the GIL means that Python in multiple threads can run faster, but basically isn't that all that changes? You want to run multiple Trio threads, you need to add...

I'd vote +0.25 for changing the behavior (but +1 for documenting things more stringently). > ("I created the fail_after object early because I wanted that to be when the deadline...