To clarify, the way I'd expect most developers to use this is not by modifying the code, but by running python in dev mode locally (-X dev or PYTHONDEVMODE=1). A link should take users to: https://docs.python.org/3/library/asyncio-dev.html#asyncio-debug-mode

Added the link 👍

Hm. I agree but that's effectively a shortcut. Pedagogically, I think it's clearer to mention the debug=True flag.

Hm. I agree but that's effectively a shortcut. Pedagogically, I think it's clearer to mention the debug=True flag.

If you say so. I didn't even know that parameter existed and can't imagine ever using it. All I need to know as a user is that this feature exists and is enabled as part of dev mode..

generally (but not always) in order.

I still find this bit awkward as it's again suggesting that order of execution is unpredictable. Can we say that the jobs are processed in the order that they were scheduled or something?

Hm. If there's phrasing you have in mind, that the folks who are wary of the queue analogy would also be on board with, I'm open to it!

This may not be the best example, as the application is expected to close at the end of main(). So the task gets cancelled anyway. i.e. Even if I keep a reference, I can get the task to not complete:

>>> async def hello():
...  await asyncio.sleep(1)
...  print("BAR")
... 
>>> async def main():
...  global t
...  t = asyncio.create_task(hello())
... 
>>> asyncio.run(main())
>>> t
<Task cancelled name='Task-10' coro=<hello() done, defined at <stdin>:1>>

If you did:

   async def hello():
       await asyncio.sleep(1)
       print("hello!")

   async def main():
       asyncio.create_task(hello())
       await asyncio.sleep(2)

Or similar, then this probably better shows the risk. This works in practice today, but is not guaranteed to work.

Neat first example!

Hm. I don't see how the second better illustrates the risk. The risk that the current example is meant to emphasize is the problem with losing references (before awaiting). As opposed to the program exiting before all registered (but unawaited) tasks finish.

The risk that the current example is meant to emphasize is the problem with losing references (before awaiting).

My point is that it doesn't show that, because main() exits regardless and the other task is not expected to continue running. As I showed above, it doesn't run past the initial iteration if we do hold references to it, nevermind if we don't.

The second example has a sleep so that main() outlives the task. So, in this case the lack of a reference could cause an issue. With a reference, the task is meant to run until completion.

Well, yeah it doesn't show the issue of GC killing off references. But none of these examples shown so far do. It's somewhat difficult to create a simple, real example. #117379

Ah, I think I see what you're saying of how folks could confuse the termination of main() with the danger of GC'd tasks. I've reworked a decent bit to clarify.

Yeah, that looks better to me.

This makes little sense to me, since the title of the second part does not say it is.

Ah, good catch. I tweaked the latter section title to include part 2.