Currently, the trio2aio and aio2trio adapters are pretty basic while run_asyncio creates a magic object and run_trio returns an asyncio.Future, requiring specialized adapters for generators and iterators. That's an unnecessary cognitive load and prone to errors, esp. as run_asyncio does more than trio2aio, which seems counter-intuitive.
We need better names for adapters. aio_from_trio or aio_as_trio should convey clearly that this the former lets us call an asyncio function from trio – trio2aio doesn't.
The adapters should return a magic object that does its work behind the scenes. No iscoroutine or isasyncgenerator etc. calls should be required, because the magic object is called differently depending on usage.
The magic objects should default to the innermost trio_asyncio loop (as taken from the contextvar when they're actually called) unless one is passed in explicitly.
Currently, the
trio2aio
andaio2trio
adapters are pretty basic whilerun_asyncio
creates a magic object andrun_trio
returns anasyncio.Future
, requiring specialized adapters for generators and iterators. That's an unnecessary cognitive load and prone to errors, esp. asrun_asyncio
does more thantrio2aio
, which seems counter-intuitive.We need better names for adapters.
aio_from_trio
oraio_as_trio
should convey clearly that this the former lets us call an asyncio function from trio –trio2aio
doesn't.The adapters should return a magic object that does its work behind the scenes. No
iscoroutine
orisasyncgenerator
etc. calls should be required, because the magic object is called differently depending on usage.The magic objects should default to the innermost
trio_asyncio
loop (as taken from the contextvar when they're actually called) unless one is passed in explicitly.