[anonymoushn]

It does something we were already doing worse than we were already doing it. In Python's case, it does it worse than we were already doing it in the same language. At least for me, this is why I don't have many nice things to say about it.

It's also fine to "prefer to be explicit", but it is weird to prefer to be explicit ONLY about whether a function can do the "switch stacks" operation on your behalf (not whether it can consume random numbers from the global RNG, not whether it can create files, not whether it can do blocking I/O, not whether it can open a server socket, not whether it can send HTTP requests, not whether it can write log lines, not whether it mutates its parameters, etc.), and to be explicit about it in a way that invites bugs that don't need to be possible to write (async functions produce a value that can then be awaited, so it's a bug to not await them when you meant to, or to await them when you didn't mean to, and it's common to write such bugs when adding an await operation to a formerly non-async function that is called by other formerly non-async functions).

[jordic]

I must say that python3.8 does a better job detecting not awaited awaitables.

Anyway,asyncio it's not new to python, the stdlib still has asyncore in it. There are still awesome web servers around (threaded) but using "asyncio" on the main thread. ZServer, medusa (look at what powers supervisor for example).

The file io thing it's still a pain, but same happens on node side.. but seems there is in the way something that will fix it.