This weird mixing was actually a side effect of me quickly coming up with a small example, sorry for the confusion. I just saw, actually using the same loop gets rid of the behavior in this case and now I'm not sure about my assertions any more. Yet it still looks like asyncio doen'st keep strong references. Hmm.
The original problem prompting my question is here: https://github.com/ldo/dbussy/issues/13 Also this is a python 3.7.1 on a current Fedora 29. > > Usually, when you're already running into a coroutine, you're using > > "await other_coroutine()" instead of > > "asyncio.create_task(other_coroutine())". > > Which is not accurate. What Ian said is accurate. One indeed may need to > schedule a coroutine in some situation. I just assumed that's wasn't > what the OP intended to do given the name of the "main" function. > > I also said: > > > But anyway, I highly recommend you to use the "await other_coroutine()" > > syntax I talked about earlier. It may even fix the issue (90% chance). > > This should indeed fix the issue, but this is definitely not what one is > looking for if one really want to _schedule_ a coroutine. Which is what I want in this case. Scheduling a new (long-running) task as a side effect, but returning early oneself. The new task can't be awaited right there, because the creating one should return already. > If the goal here is for the task created by main() to complete before > the loop exits, then main() should await it, and not just create it > without awaiting it. So if this happens somewhere deep in the hirarchy of your application you would need some mechanism to pass the created tasks back up the chain to the main function? Greetings. -- https://mail.python.org/mailman/listinfo/python-list