Thanks for the response.

> and an API with more choices is not necessarily better.

I certainly agree, and that's why I try to implement MicroPython's uasyncio solely in terms of coroutines, without Futures and Transports. But I of course can't argue for dropping Transports in asyncio, so the only argument I'm left with is consistency of API (letting use coroutines everywhere).

> I'm sure this has come up before, I could've sworn it was you, sorry if it wasn't.

No, I brought issue of Futures dependency (yes, that was wide and long discussion), then about yielding a coroutine instance as a way to schedule it. But during the time I'm on python-tulip, I didn't remember someone bringing up issue of asymmetry between read & write, but I would imagine someone would have done that before me. (Which might hint that the issue exists ;-) ).

> the common mistake (amongst beginners) of forgetting the "yield from" or 'async' would be much harder to debug

So, this is not first time you provide this argument for different cases, one would think that this pin-points pretty serious flaw in the language and it's priority to find a solution for it, and yet PEP3152 which does exactly that was rejected, so maybe it's not that *serious*. Indeed, it's common sense that it's possible to make a hard to debug mistake in any program, and in any concurrent program (doesn't matter of which paradigm) it's order of magnitude easier to do one and harder to debug respectively. But asyncio does have tools to debug such issue. And one would think that easiest way to preclude mistake is to avoid inconsistencies in the API.

I know there's a very find balance between all the arguments, and only you can know where it lies, but kindly accept external feedback that the above explanation (syntax is more prone to mistakes) looks like universal objectivized rejection in rather subjective cases.

What saddens me here is that this decision puts pretty high lower bound for asyncio memory usage (and I tried hard to prove that asyncio is suitable paradigm even for smaller, IoT-class devices). It's also hard to argue that Python isn't worse than Go, Rust and other new kids on the block - because indeed, how one can argue that, if even the language author uses argument "language syntax, while exists, isn't good enough to do the obvious things".