theelous3
commented
6 years ago hi :)
curio and trio have deep similarities both in overarching api design and underlying constructs and syntax. This means that it's not particularly difficult or insane to write happily interoperable wrapper functions and so on.
asyncio does not share either of those, and even within its self lacks a cohesive api. They are very disparate approaches.
My gut reaction when reading this was - as often gets me in trouble - "maybe we could?"
But no. It's the general opinion of the authors of this lib that asyncio was a mistake. There are enough utilities written for asyncio that it does not need any further ecological bolstering that may come about from giving it access to libs written for curio and or trio.
Of note, even there was no fundamental objection to asyncio, it's still too different an api to reasonably maintain.
A thought I had writing this was that perhaps we could write a wrapper around asyncio and then support that, but, well, that would just be a bad rewrite of curio / trio.
asmodehn
Possible values are <dict_keys(['curio', 'trio'])>, not <asyncio>Any specific reason to not allow asyncio there ?