I've pushed a couple of boulders up this particular hill, and none of them have stayed there.
Trouble is, Python is a great stack for communicating with networked instrumentation - except when asyncio gets involved. And, talking with devices over a network is a picture-perfect use case for asyncio.
My last attempt was "tworoutines" [1], which tried to marry async and sync functions under a common wrapper. At the time I wrote it, it was clear tworoutines ran contrary to the direction Python was taking asyncio. Without nest_asyncio [2], It was fairly brittle and has become more brittle over time. The primary developer for nest_asyncio unfortunately passed away earlier this year.
There is a long discussion here [3, 4], including representation from Python higher-ups as well as other people writing instrumentation/science software. In other words, it's not just us.
I've pushed a couple of boulders up this particular hill, and none of them have stayed there.
Trouble is, Python is a great stack for communicating with networked instrumentation - except when asyncio gets involved. And, talking with devices over a network is a picture-perfect use case for asyncio.
My last attempt was "tworoutines" [1], which tried to marry async and sync functions under a common wrapper. At the time I wrote it, it was clear tworoutines ran contrary to the direction Python was taking asyncio. Without nest_asyncio [2], It was fairly brittle and has become more brittle over time. The primary developer for nest_asyncio unfortunately passed away earlier this year.
There is a long discussion here [3, 4], including representation from Python higher-ups as well as other people writing instrumentation/science software. In other words, it's not just us.
[1]: https://github.com/gsmecher/tworoutine
[2]: https://pypi.org/project/nest-asyncio/
[3]: https://bugs.python.org/issue22239
[4]: https://github.com/python/cpython/issues/66435