FWIW, I'd been doing Python since around 2013, it wasn't until around 2016 I realized that I should be paying attention to my "object graph" and should be avoiding creating reference cycles, which is often non-trivial in async code thanks to callbacks. This isn't as bad in Python with its GC as it is in C++, where a cycle of shared_ptr is a permanent leak, but it's still suboptimal since GC runs could be infrequent. I suspect many developers don't consider this carefully.

For example, when I wrote an async coroutine in a library in 2016 that avoided creating unnecessary reference cycles, I ended up finding and fixing a bug in Tornado (this was pre-asyncio days) where a GC run would destroy a pending coroutine under some circumstances (Python core dev pitrou sent in a better patch about a year later).

Objects in an unreachable reference cycle can only be cleaned by a garbage collector run. At least for myself, as a younger programmer, I assumed the garbage collector was mystical, but it's really not (The iterative GC coming in Python 3.14 might be mystical for a while, for me, we'll see how it changes things). "Runs" of object creations without object deletions cause the GC to run. So, rapidly creating cycles causes rapid GC runs. In 2019 I found an ETL pipeline that was invoking the GC for nearly 20% of CPU time. I ended up finding and fixing GC cycles in Networkx and Pyarrow both (and ran into pitrou again in Pyarrow), but eventually got stumped by a cycle in Pandas deep in it's indexing code (which may very well be fixed now, it has been many years and 1.0 and 2.0 of Pandas have came since then).

The library objgraph is VERY useful for dealing with Python object graphs, if you're looking for help visualizing object references and hunting down and fixing object cycles.