Hello,
> And I personally
> would have real hard time explaining people while read operation should
> be called with "yield from" (or "await" soon), while its counterpart
> write - without.
>
No. This is actually very simple and obvious: when you call read, you
need the result of that to continue working, with write, you don't.
So you need to wait for the former, but not for the latter.
There simply is no symmetry between read and write when it comes
to asyncio. This is like asking "why does write have a parameter
data, while read doesn't?", well, because, they are different.
The entire coolness of asyncio lies in the fact that you clearly mark
the places where concurrency enters. By making just everything a
coroutine, this great idea just disappears. And write is a very good
example for this. Sometimes in my code I have two writes:
writer.write("something")
writer.write("else")
because this is asyncio, I know that those two writes will be called
directly after each other, and that the data goes out into the world
just like that. This is the large advantage over multi-threaded
programming: there some other thread might write something
in between those lines, and the result is just some mingled data.
Sure, in multi-threaded programming I can just use mutexes. But
you quickly run into large problems with hardly debuggable code.
So in short: when designing an API for use with asyncio, try
to limit the use of coroutines to where it is really, really
necessary.
Btw, is there anyone who could comment on my original posting,
that StreamWriter.drain cannot be called concurrently?
Greetings
Martin
