These are reasonable arguments but I largely disagree as someone who might not meet your threshold of sophistication. * Apparently the "crude" syntax is supple

These are reasonable arguments but I largely disagree as someone who might not meet your threshold of sophistication. * Apparently the "crude" syntax is supplemented by an asyncio library providing more fine grained controls without further complicating Python syntax. * I don't think gatekeeping is a very good argument against a language feature. Obviously Node is special because it forces you to use async even if you just want to write boring old blocking code, but in Python this is strictly optional, and having it as a language feature doesn't mean "most Python programmers" are suddenly going to consider it, just like most Python programmers don't consider metaclasses. I'm certain the vast majority of Python programmers aren't having this inner debate of "you can have a synchronous function, or an asynchronous function, pick one"; it's been five years and four major Python versions and I've never heard anyone complaining about this choice when it's not relevant. * Meanwhile, I've personally used native asyncio for both of your distinct common use cases (replaced threading-based solutions, saw saner code and some performance improvements), so I consider it a success. * Ugliness is subjective, I'd say adef/afor/awith/etc. are more of a wtf if I'm new to the language, and you end up with more keywords. The async keyword also leaves the door open; async def/with were introduced in py35 while async for was introduced in py36, so it is conceivable that the async keyword could be expanded to more use cases in the future.