Thanks for the docs update; I didn't realize these were little-known. Streams shouldn't have callbacks, the existing stream convention for detecting EOF (empty read) should be fine. However I agree that readexactly() should raise an exception. A subclass of EOFError is fine.
On Thu, Jan 23, 2014 at 3:38 AM, Victor Stinner <[email protected]> wrote: > 2014/1/23 Glyph <[email protected]>: >> On Jan 22, 2014, at 7:33 AM, Guido van Rossum <[email protected]> wrote: >> >>> The solution is simple: write that logic as a separate method marked >>> with @coroutine, and fire it off in data_received() using async() (== >>> Task(), in this case). E.g. >> >> Wouldn't that process each subsequent TCP segment in a parallel coroutine, >> thereby with multiple segments of data stomping on each other if they're >> yielding during processing? >> >> It seems to me that the real solution to do this (IntNReceiver) in the >> coroutine style would be to use StreamReader, (...) > > The StreamReader and StreamWriter classes were not well documented. I > moved all stream things to a new page in asyncio documentation and I > added a simple example using open_connection() to show how to use > streams. > > I spoke with Thibaut Dirlik (who asked the same question, how to use a > coroutine in a protocol). He didn't know StreamReader and implemented > its readline() method :-( He now wants to use StreamReader. > > I still don't understand yet when protocols should be used and when > streams should be preferred. Are stream classes the high-level API? > > I only found one major difference between protocols and streams: how > EOF is handled. It's not possible to call a function on EOF when using > a StreamReader. Protocols have a eof_received() method. If a stream > reader is waiting for incoming data, it wakes up the coroutine. By the > way, I don't like the current behaviour of readexactly() on EOF: I > opened the issue #111. > > Victor -- --Guido van Rossum (python.org/~guido)
