I always knew asynchronous programming is awesome. And having a language support for it really help its adoption by limiting the existence of incompatible event frameworks which would be a pain to use together.
However, the asynchronousness is very contaminating. This makes it difficult to make threads and asyncio coexist in a single application as a transition period while the thread model is replaced with the async one. And a smooth transition is of course needed because a series of smaller changes that are separately testable for correctness is a lot easier to develop that one large chunk of rewrite.
Unless I'm mistaken, there's no obvious way to have a function run a coroutine in a given event loop, no matter if the loop in running or not, no matter if it's running in the current context or not. There are at least 3 cases that I can see: 1) The loop isn't running -> run_until_complete is the solution. 2) The loop is running in another context -> we might use call_soon_threadsafe and wait for the result. 3) The loop is running in the current context but we're not in a coroutine -> there's currently not much we can do without some major code change.
What I'd like to propose is that run_until_complete handle all three cases. Including the third, which imply that the event loop could be run recursively.
I also found out that the loop argument to most standard asyncio classes has been deprecated. I think it's pretty crazy as it prevent objects from being instanciated in one thread and used in another. Which would again imply significant code change in one single go for applications trying to switch from threads to asyncio.
Did I miss an obvious way to make the migration from threads to asyncio easier? It becomes harder and harder to not believe that python is purposfully trying to make this kind of migration more painful.
Best regards, Celelibi