Hi list, sorry for being a bit late, but I only discovered that post recently... I've a couple concerns: 1. update now 3.6 is out, the post should be rewritten or new one made, mainly because this post if what inquisitive minds find... 2. asyncio for whom? I've presented asyncio tutorial of sourts at a local Python meetup. I've noticed that asyncio documentation is pretty hard to understand. There are many concepts and a ton of caveats. I now finally understand why, and I think it comes down to asyncio being 2 distinct things: a. asyncio is a standard library meant to be used as a framework by other, higher-level, 3rd party libraries that are still written by very smart developers, and b. asyncio is a way for average joe developers to write async code. I used to think I was in cat.a., but clearly I'm more of a cat.b. dev :( I really with there was decent advice how to use asyncio/aiohttp/pytest-asyncio/curio? etc. Something along the lines of: * if you want fire-and-forget (e.g. async logging), do xyz1 * if you want a worker task, do xyz2 * if you want a synchronisation point, do xyz3 * if you want ... I'd love these to be reflected in the API that Python advertises. For example, I'd rather think of a Future() as a thing that provides a result, meaning it's commonly shared by multiple tasks, meaning it would by default be shielded. Should a Future() die if it's garbage-collected, like a generator or should it conitnue? These are areas where Python should provide best practice. Task cancellation (just like thread cancellation) is by definition(?) arcane, and I'd argue average developer should be advised against... I for one, still can't make up my mind what's better -- to cancel bottom or top frame when task being cancelled awaits something that awaits something else, etc... Should provision to block cancellation even exist? What would be the best quorum for these discussions? Cheers, d. P.S. I'm trying to avoid "coroutine" nomenclature on purpose